去年年底，一个朋友介绍了一个单子。
某制造业公司，100多人，想做一个员工报销审批系统。需求不复杂：移动端提交报销单，PC端多级审批，财务对账导出。
对方问我多久能做完。
我想了想，按照以往的节奏，老老实实报了个数：30天。
对方沉默了几秒，说：
"我们CFO那边最多等3周，你能不能快一点？"
我说让我想想。
挂了电话，我打开Cursor，把需求文档扔进去，盯着屏幕想了十分钟。
然后我回了电话，改口了：
"5个工作日，可以交付。"
对方以为我在开玩笑。
一、为什么敢报5天
不是因为我变快了。
是因为我的工作方式变了。
以前接外包，我的时间是这么分的：
需求澄清：2-3天（反复拉齐，来回确认）
技术方案：1天
编码实现：15-18天
联调测试：5-7天
修改返工：3-5天（需求理解偏差导致）
---
合计：约26-34天
其中修改返工这一块，是最大的黑洞。
不是代码写错了，是需求理解出了偏差。写到一半客户说"不是这个意思"，然后推倒重来，这5天就这么没的。
用了AI之后，我发现了一件事：
AI逼着我在动手之前就把需求想清楚了。
不是AI帮我分析需求，而是：每次我把需求喂给AI，AI都会"理所当然"地按字面意思理解，然后生成一份我没想到的方案。
看到那份方案的时候，我会本能地想：这里不对，那里缺了一个场景，这个边界情况没处理。
这个过程，本质上是在逼我主动想清楚。
二、第一天：需求澄清的方式变了
拿到需求文档之后，我做的第一件事，不是打开IDE，也不是开始写代码。
我把需求文档喂给Claude，让它做了一件事：
你是一个有10年经验的产品经理。
请阅读以下需求文档，然后以"一个即将实现这个功能的开发者"的视角，
列出你认为文档里没有说清楚的问题。
重点关注：边界情况、异常流程、业务规则的歧义之处。
[粘贴需求文档]
AI给了我一份清单，里面有9个问题。
我自己原来只想到3个。
其中有几个我当时看到就头皮发麻：
- 报销单被驳回之后，是回到发起人重新提交，还是直接关闭？
- 多级审批中，如果中间某个审批人离职了，这条单子怎么处理？
- 财务导出的金额，是按提交日期算，还是按审批通过日期算？
这三个问题，任何一个如果我在写代码到一半才发现，都要改底层逻辑。
我把这9个问题整理成一张表，发给客户，约了半小时电话对齐。
对方的IT负责人看到这份清单，停顿了一下，说：
"你问的这些，我们自己内部都没想清楚。"
电话开了将近一个小时，不是我在解释技术方案，而是他们在讨论业务规则。
那一个小时，值了。
三、第二天：方案设计，AI出初稿，我来裁
需求对齐之后，下午用来做技术方案。
这部分我没有让AI直接出方案。先花了40分钟自己想了一个大框架：表结构、审批流引擎的设计方向、移动端和PC端的接口边界。
然后把我的方案丢给AI，让它找问题：
以下是我的技术方案初稿，背景是一个100人规模公司的报销审批系统。
请帮我：
1. 找出设计上明显的缺陷或遗漏
2. 指出哪些地方在当前规模下有过度设计的嫌疑
3. 给出你认为更合适的替代建议
AI指出了两个点，都很准。
第一，我设计了一套通用审批流引擎，支持动态配置审批节点。
AI说：100人公司，3级固定审批，用通用引擎是过度设计。硬编码3个审批状态，代码量减少60%，维护成本更低，够用就行。
我改了。
第二，我计划用WebSocket做审批实时通知。
AI说：报销审批不是即时通讯，不需要实时性，定时轮询或者推送通知就够。WebSocket引入了连接管理的复杂度，得不偿失。
我也改了。
这两个改动，直接砍掉了我原来估算里4-5天的工作量。
四、第三天和第四天：编码，AI做80%，我做那20%
进入编码阶段，是Cursor发力的时候。
我把自己的开发节奏整理了一下，和以前对比：
以前的写法（一个接口的例子）：
1. 打开IDE，建Controller
2. 写参数校验
3. 调Service
4. 写Service逻辑
5. 写Mapper
6. 写异常处理
7. 写单元测试
总耗时：40-60分钟/接口
现在的写法：
1. 描述清楚这个接口要做什么
2. AI生成完整代码
3. 我review：业务逻辑对不对？边界情况有没有？安全隐患有没有？
4. 调整10-20%
总耗时：10-15分钟/接口
速度是以前的4倍，但更重要的是：我的时间从"打字"转移到了"判断"。
这个报销系统大概有23个接口。两天，完成了全部接口开发和核心业务逻辑的单元测试。
当然，AI也有不会的地方。
这个系统有一个业务规则，需求文档里有一句话几乎一笔带过：
"报销金额超过5000元，需要提交原始发票扫描件。"
AI按字面意思实现了：超过5000，接口必填attachment字段，否则报错。
但我和客户对完需求之后知道：这里有一个隐藏规则——交通费不受这个限制，因为高铁电子票不是"原始发票"。
这条规则，AI不知道，因为文档里没写。
这段代码，我自己重写了。
AI生成的80%，省的是打字的时间。剩下的20%，才是这活儿真正值钱的地方。
五、第五天：省出来的时间，我用来做了一件事
第五天上午，联调测试，修了两个小bug，下午三点，部署完毕。
剩下两个多小时，我本可以直接交付，等对方验收。
但我没有。
我做了一件以前从来没时间做的事：
写了一份《三个你们可能没想到、但迟早会遇到的问题》备忘录。
问题1：审批人外出时的代理机制
你们现在的流程是：审批人直接审批。但半年内，你们一定会遇到这种情况——财务总监出差一周，有8张报销单堆在那里，没人能批。
建议：在系统里增加一个"代理审批人"配置，平时不用，需要的时候开启。现在做成本低，以后加进去要改底层逻辑。
问题2：报销数据的对账周期
现在财务导出是全量导出。三个月后，数据量上来，每次导出可能要跑10秒以上。
建议：现在就按月分区存储，导出时默认选当月。这不是性能优化，是习惯养成，早点定下来。
问题3：审批记录的法律效力
你们现在审批记录存的是"谁在什么时间点了同意"。但如果将来有财务纠纷，这条记录能不能作为凭证？
建议：审批时同时存一个报销单的快照（JSON格式），防止有人事后改报销金额，然后说"我审批的不是这个数字"。
我把这份备忘录发给了客户的IT负责人。
他看完，沉默了几分钟，回了我一句话：
"第三条，我们自己根本没想到。你等一下，我要转给CFO看。"
半小时后，他又回来：
"CFO说这个快照的事要做。能加到这次交付里吗？"
我说可以，一天搞定。
六、客户说"下次还找你"，真正的原因是什么
验收那天，IT负责人和我说了一句让我印象很深的话：
"说实话，5天交付我当时以为你在糊弄我。但最后这个备忘录，比系统本身更值钱。我们以前找的外包，交付完了就消失了，你是第一个主动帮我们想后面的事的。"
他说下次有需求，还找我。
我后来想了很久，这件事的逻辑是什么。
如果我还是按以前的方式开发，30天才交付，那5天联调加返工就已经把我榨干了，根本没有心思写什么备忘录。
AI压缩的，不只是交付时间。
AI压缩的，是"赶工焦虑"。
有了余裕，我才能做那些**让客户记住你、而不只是"验收通过"**的事。
接外包，很多人把竞争力建在"更便宜"或者"更快"上。
但客户真正愿意持续付钱的，是让他感觉被认真对待的人。
这一点，AI帮不了你。
但AI可以帮你腾出时间，去做这件事。
七、一套可以复用的工作流
把这次的流程整理下来，可以直接用。
第一步：需求澄清（用AI挖问题，不要自己猜）
Prompt模板：
你是一个有10年经验的产品经理。
以"即将实现这个功能的开发者"的视角，
列出以下需求文档中没有说清楚的问题，
重点关注边界情况、异常流程、业务规则歧义。
[粘贴需求文档]
拿到清单之后，打一个电话把问题全部对齐。这一步省的是后面的返工。
第二步：方案设计（自己出初稿，AI来挑毛病）
不要让AI直接出方案，自己先想清楚框架，再让AI找过度设计和遗漏。这个顺序很重要：自己先想，才能判断AI的建议是否适合自己的场景。
第三步：编码（Cursor主力，你做判断）
单次生成不超过一个模块，每次生成完必须review。安全相关、资金相关的代码，不管AI写得多漂亮，必须人工核查。
第四步：用省出来的时间，做AI做不了的事
交付之前，留出半天，站在客户的角度想：三个月后他们会遇到什么问题？现在告诉他，比他自己踩坑之后找你要强得多。
这一步，就是下一个单子的敲门砖。
写在最后
有人问我：你用AI做外包，会不会被客户觉得不踏实？
我反问他：你写代码的时候用Stack Overflow，你的客户会觉得不踏实吗？
工具是手段，交付是结果，信任是积累出来的。
AI让我快了，但让客户信任我的，是那份备忘录，不是Cursor。
快，只是给你赢得做其他事情的机会。
至于那个机会你用来干什么，AI管不了。
你用AI接过外包吗？有没有类似的经历？欢迎评论区聊聊。
后端AI实验室 不讲概念，只谈实战 代码开源，每周更新
