它们花了 5 个通宵，把我的产品彻底重做了
它们花了 5 个通宵，把我的产品彻底重做了
全程没打开过 IDE。三个模型轮番上阵，写了前端、后端、测试、修了 bug。我只负责一件事：告诉它们要做什么，判断结果对不对。
前几天读到一篇文章。
OpenCode，16 万 Star，运营了快两年的明星项目，作者决定全部推倒，从零再来。
他的逻辑很简单：每件事都要迭代三次才能做对。0 是原型，1 是验证，2 才是真正搞懂了问题之后，重新做一次选择。
这句话让我想起了去年断断续续参与的一个招投标产品。它已经把想法变成了能运行、能讨论的产品，也让我啃下了不少行业知识。后来我没有足够的精力继续跟进，但那些只有真正做过之后才会形成的判断，一直留在那里。
后来精力跟不上，项目搁置了，但那些经验没丢。
干脆做个实验：
不搭架构，不写代码， 只把业务经验、产品目标和验收标准交给 AI。 让它们从零开始， 看看能折腾出什么。
说干就干。
五个通宵之后，它们把答案交了回来
下班前，我把目标、边界和验收标准交代清楚，留下一句：
你认真干，我去睡了，明早验收。
然后就真的去睡了。
夜里，AI 自己拆任务、写代码、跑测试、处理报错。第二天早上我起来验收，指出哪里不对，做取舍，再把反馈交给下一轮。
五次”晚上交任务、早上验成果”之后，它们交回来一个能跑、能测、能完成真实业务闭环的产品。
- 数据库、后台任务、断线恢复
- 原文证据定位、Agent 工具调用
- 183 个提交，约 6.7 万行新增，2,210 行删除
- 194 个测试文件，800 项自动化测试通过
数字不等于质量，也不全是业务代码，这个我有数。
但它们让我第一次真切感觉到：AI 能承担的，已经不只是几个函数了，而是一整条链路——从架构到实现、从测试到调试、从翻车到返工。
真正被推倒的，不是代码
旧产品用 Vue、Java 和 Dify。推倒重来，不是因为它失败了。
恰恰相反，它完成了原型最重要的使命——把模糊想法变成一个能跑、能讨论、也能被质疑的东西。标讯雷达、招标文件解析、竞对分析、研判报告，一个个功能做下来，我慢慢看清了哪些字段只是”有”，哪些信息真的会影响一家公司投不投。
真正值钱的不是代码，是这些一口一口啃出来的判断。
所以这次我交给 AI 的，不是一份需求文档，是过去一年里慢慢长出来的业务直觉。
而这次重做，最根本的改变也不是换了技术栈。
旧产品的逻辑很典型，也很”页面”：
首页 → 标讯查询 → 项目详情 → 甲方查询 → 竞对分析 → 收藏项目 → 研判报告 → 用户自己综合判断每个页面都有用，但所有信息散在不同地方，用户得自己在脑子里把它们串起来。去哪看、下一步干什么、这条信息和那条信息什么关系——全靠自己搬、自己拼。
Agent 思路把基本单位换了：
用户描述目标 → Agent 理解企业背景 → 调用搜索/解析/分析工具 → 组织判断依据 → 创建项目或发起研判 → 用户在关键节点做决定
区别很简单：传统产品把能力做成页面，等你来点；Agent 产品把能力做成工具，按目标自己调。
但这不是说页面就该消失。
标讯列表适合批量浏览，原文预览适合核对证据，项目驾驶舱适合看状态。它们只是不再彼此孤立——从需要用户自己串的入口，变成了 Agent 工作流中的证据面板、控制面板和结果面板。
三个模型，像团队一样配合
这次实验有三个 AI 角色：
- Claude Fable 5 — 架构、边界、技术决策
- Kimi K3 — 前端页面、交互、视觉
- Codex — 后端、数据库、自动化测试、调试与收尾
- 我 — 业务经验、定方向、做取舍、给反馈、最终验收
它们不会自己坐到一起开会。一个模型也不知道另一个模型刚做了什么。真正完成交接的，是一组可以传阅的工程产物：
业务目标 → 设计规格 → 实施计划 → 分支与提交 → 自动化测试 → 浏览器验收 → 修复与合并
一开始我想得很大：一个类似 ChatGPT 的投标智能体平台，文件解析、信息抽取、研判、制标、审标，甚至还有在线文档。
AI 做的第一件重要的事，不是写代码。
是删需求。
第一个闭环被收缩成一句话：上传文件、解析、抽取、展示、定位证据。
基础设施也一样。没有一上来就为想象中的规模加一堆中间件，而是先把后台任务、数据和恢复路径做扎实。
当前最重要的问题不是”能不能承载未来所有场景”，而是”今天能不能把一件事可靠地做完”。
三模型协作，不是让它们开会，而是让设计文档、测试和 Git 成为它们共同的语言。
代码生成变便宜之后，边界反而成了最稀缺的东西。人最需要做的不是逐行指导 AI，而是持续回答：为什么做、做到什么程度算完成、哪些能力现在坚决不做。
它第一次不像 Demo 了
第一个真正跑通的产品闭环，是招标文件处理：
上传 Word/PDF
→ MinerU 解析
→ DeepSeek 抽取
→ 对话中流式展示进度
→ 打开结构化结果
→ 点击证据定位原文
光看功能列表没什么特别的。但翻译成用户体验，区别就出来了：
- 页面关掉，后台任务还要继续跑
- 重新打开，系统要知道刚才跑到哪了
- 模型说”预算 508 万”，你得能点回去看原文
- 解析失败，界面要说清哪个阶段出了问题、下一步怎么办
- 切换项目，上一份文件的结果不能串过来
这就是我说的”产品级”——不是上线了、不是有客户了，而是一个能跑、能测、能完成真实业务闭环的版本。
Demo 关心的是”演示这一次能不能成功”。产品关心的是”第二次、第一百次、以及失败的那一次，会发生什么”。
真正让我觉得它不像 Demo 的瞬间，也不是页面变好看了，而是我刷新浏览器、切换项目、故意制造失败之后，它仍然知道发生了什么。
从文件工具，长成了 Agent 平台
文件闭环跑通之后，产品又往前走了一步：它不再只是”上传文件、返回结果”的工具，而是项目里的工作平台。
用户可以在项目中直接对话。总 Agent 理解目标和当前项目，寻标、制标、审标这些专业能力变成它可以调用的工具。
耗时的任务进后台，有风险的操作在关键节点停顿等人确认。
比如用户说：
从今天推荐的商机里，挑一个适合我们的，加入项目开始研判。
传统产品怎么做？
找寻标入口 → 设条件 → 翻列表 → 看详情 → 收藏 → 跳到研判页面。每一步都要自己找。
Agent 怎么做？
读企业画像 → 搜近期项目 → 解释为什么匹配、有什么风险 → 等你确认 → 创建项目 → 发起研判 → 把结果和下一步交到你面前。
以前，是你学产品有哪些功能。现在，是产品学你想完成什么。
这就是”Agent 产品”和”传统软件加聊天框”的区别。聊天框只是入口，真正的新结构是：目标、上下文、工具、长任务、证据和人的判断，一起组成一个闭环。
真正让我服气的，是它会返工
我过去判断 AI 能不能做产品，看的是它第一次能不能写对。后来我发现，更重要的是它写错之后会怎么处理。
页面很完整，为什么全是 Mock？
有一次，产品看起来已经很完整：能上传，能显示进度，也能返回结构化结果。但我在验收时越看越不对，所有结果都太像预先准备好的模拟数据。
这个问题不是 AI 主动发现的。是人先对结果产生了“不对劲”的感觉。
收到反馈后，AI 沿着完整链路一路排查：
- 环境配置是否存在
- Provider Factory 最终选了哪个实现
- 任务记录里保存的解析器是什么
- 抽取结果引用的块 ID 是否来自真实文档
最后确认：界面完整 ≠ 真实业务路径已接通。缺少配置时，系统悄悄走到了 Mock 边界。
修复不只是把开关从 mock 改成 live。更重要的是重新划清数据边界：
- 真实任务不能悄悄回退到模拟结果
- 演示数据必须明确标注
- 第三方服务未真实验证时，不能写成”已通过”
这个故事提醒我：视觉完成度最容易制造错误的信心。一个页面可以像产品，只有数据从真实入口走到真实结果，才构成业务闭环。
类名在，测试也过了，文字还是黑的
另一次问题小得几乎可笑：选中的卡片应该是蓝底白字，浏览器里却仍然显示黑色。
AI 第一次修复后，代码中已经出现 text-white/80，测试也断言这个类名存在。从代码和单元测试看，事情已经结束。
但我打开浏览器，文字还是黑的。
继续排查才发现：CSS 根本没被生成出来。”类名写进了代码”和”用户最终看到白色”，是两件事。
于是验收标准被改写：不再检查字符串里有没有某个 class，直接检查浏览器渲染出来的真实颜色。
这个改动很小，却很能说明问题——测试如果只验证实现细节，就可能非常忠实地证明一个假修复。
AI 能很快补测试，但人仍要问：这个测试究竟在保护用户结果，还是只在保护我们对代码的想象？
自动化全绿，刷新后配置却丢了
第三个故事发生在全局对话设置上。自动化测试、类型检查和构建都通过了；同一页面切换设置、跨菜单同步也正常。直到真实浏览器验收时刷新页面，设置又回到了“自动”。
仍然是人先在日常操作里撞见问题，AI 再去定位原因。它检查了共享 store、localStorage 和组件订阅时序，发现初始化发生得太晚，默认值覆盖了持久化值。
修复之后，又重新验证了跨菜单共享、刷新恢复、自动重置和浏览器控制台，并留下回归覆盖。
这正是自动化测试从 267、327、752、776 一路增长到最终 800 项的意义。每发现一个真实问题，保护网就多一根线。但“800”不是护身符。它来自不同阶段不断累积的用例，证明的是返工留下了痕迹，不是以后不会再出错。
这几次经历让我服气的，不是 AI 不犯错，而是它能在我说”这不对”之后，跨层排查、修复实现、补回归测试，再打开浏览器验证用户最终看到的结果。
AI 能替你干很多活，但不能替你在错误面前感到”不对劲”。
人还是产品质量的最后一关。AI 能读日志、查配置、改代码、跑测试、比较截图、操作浏览器——但什么才算正确，为什么一个细节会伤害用户信任，这些仍然是人用业务经验来定义的。
五个通宵之后，我认了五件事
第一，AI 已经能走完一整条工程链路了。
不只是写函数、修 bug。只要目标、边界和验收标准说清楚，它能参与架构设计、前后端实现、数据库、自动化测试、浏览器验收、故障定位和工程收尾。
但我不会把它包装成”完全自主开发”——方向是人定的，关键取舍是人拍的，偏差也多次是人先发现的。
第二，产品判断没有贬值，反而更贵了。
AI 能很快把对的方向做出来，也能把错的假设实现得异常完整——完完整整地跑偏。
AI 降低了写代码的成本，却抬高了做判断的价值。
第三，规格、测试、Git、浏览器，正在变成新的开发界面。
“零 IDE”不等于零工程。设计规格画边界，测试描述行为，Git 记录每一次改变，浏览器回答用户究竟看到了什么。
过去我在编辑器里改代码，这次我更多是在描述目标、确认边界、比较方案、验收结果。工程没消失，只是操作工程的界面变了。
第四，多模型的意义是分工，不是 PK。
架构、交互、后端、收尾，需要的能力倾向不一样。让模型待在适合它的位置上，比把同一句 prompt 发给三个模型比谁分高更有用。
多模型协作的难点也不在调用数量，而在交接质量——没有稳定的规格和测试，模型越多，信息损耗越大。
第五，速度必须拴在正确的反馈回路上。
这次最有效的方法不是一开始就把终极形态描述清楚，而是一步一步来：
- 先让文件真能解析，再让结果能追溯原文
- 先让项目能恢复，再让 Agent 能调用工具
每次只多迈一步，每步都拉回到真实浏览器、真实数据和真实用户目标上去验证。
速度本身不是优势，把速度关进正确的反馈回路里，才是。
我不再问 AI 会不会写代码了
旧产品帮我搞懂了招投标这门生意。这次实验让我有机会放下那种”一个功能一个页面”的旧习惯，把能力重新组织成目标、工具、上下文和任务闭环。
五个夜间执行窗口，证明不了 AI 不需要人了，也证明不了这个版本能扛住大规模生产。
它证明的事更具体：
人在下班前画好边界，AI 在夜里干活，人第二天验收纠偏。
在这种异步接力里，AI 已经能扛起过去需要好几种工程师角色配合的大部分执行链路。而且翻车了会排查、会返工、会恢复。
五个通宵之后，我不再问 AI 会不会写代码了。
我开始问： 什么问题值得做成产品？ 哪些判断必须由人死死守住？ 当实现成本断崖式下跌，我们能不能把更多时间花在理解用户、选择方向和定义”什么是对的”上？
写代码不再是瓶颈之后，你最想把自己的时间花在哪？
附：Token 都花在哪了
附：晚上远程偷偷监控
