最近一段时间，我把工作流从 Cursor 切到了 Claude Code，也把工作场景从 IDE 切到了 CLI。表面上看，这是工具替换；实际上，这是编程范式的转变。 过去，AI 更像副驾驶：我握着方向盘，它在旁边提醒、补全、建议。现在，AI 更像主驾：我给目标、给约束、给验收标准，它自己拆解任务、编码、修复、提交。我的角色从“写代码的人”，慢慢变成“提需求的人 + 验收交付的人”。 这种变化有点像从白盒走向黑盒。以前我会盯着每一行实现，担心命名、结构、边界；现在我更关注最终是否可用、是否稳定、是否可持续迭代。不是说代码质量不重要，而是质量控制点前移到了流程设计和测试设计。
为什么说我是“养父”
我一直相信，AI 早晚会长成能独立完成需求的 Agent。
但现阶段，即使是 Claude Code，直接丢一句“实现这个需求”，交付依然常常不可控：功能可能做出来了，但边界、回归、稳定性不一定可靠。
所以“养父”的意思不是替 AI 干活，而是教它做事。
像带新人一样，先给它方法，再要求它按方法闭环。
我在做的，其实是两层输入
要让 Agent 稳定交付，必须把输入拆成两层：
- 方法论（稳定层）：需求评审、方案设计、代码实现、测试回归、问题闭环。
- 实时知识（变化层）：代码仓库、代码规范、PRD、UI 稿、接口现状、环境约束。
很多所谓“AI 不稳定”，并不是模型本身不行，而是两层输入混在一起：
该固化的没固化，该实时注入的没注入。
标准交付流程：先做对，再做稳
我给 Agent 的基线流程是：
- 需求评审：澄清目标、边界、不做什么。
- UI 评审：确认交互路径和状态变化。
- 技术方案设计：拆模块、定接口、梳理数据流。
- 技术方案评审：提前暴露风险点。
- 代码开发：按方案实现并分步提交。
- Code Review：检查逻辑、可维护性、回归风险。
- 部署与测试：跑用例、看日志、验行为。
只要测试发现问题，就回到开发修复，再重跑部署和测试。
这不是一次性交付，而是循环交付。
我踩过的坑：Harness 不够，必须上 Meta Harness
第一版我按 Harness 思路做：Agent 先设计，我来挑问题，它再改。
这套方式能跑起来，但有个致命问题：质量上限仍然是我。
只要我没发现问题，它就可能带着缺陷通过。
这本质上是“人工兜底系统”，不是“自进化系统”。
后来我引入 Meta Harness：不只盯它有没有做完，还盯它有没有学会。
一句话概括：不是监督 Agent 做任务，而是监督 Agent 学会做任务。
Meta Harness 的核心闭环
Meta Harness 重点不在“修一个 Bug”，而在“补一类能力”。
我现在固定跑四步：
- 自检：Agent 先按清单自查并提交问题与修复方案。
- 归因：每个漏检都要解释为什么没发现（流程缺口、知识缺口、规则缺口）。
- 升级：把归因写回方法论、检查清单、提示模板。
- 复验：用同类场景回放，验证新规则是否真的生效。
如果它没发现问题，我会指出问题，再追问两句：
“你为什么没发现？”“下次靠什么机制提前发现？”
同时让它整理“错题集”，把每次漏检沉淀成可复用规则。
目标很明确：从“我发现问题，它来修”，进化到“它先发现问题，我来抽检”。
现实瓶颈：测试和设计输入仍是硬骨头
当前最大的挑战仍是测试，尤其前端的端到端测试。
真实环境里还有 Android、iOS、跨端技术栈并存，再叠加公司内部调试工具，完全自动化在很多场景下仍然不现实。
这也是为什么今天很多关键环节仍需要“养父”亲自执行：
不是 Agent 不会做，而是复杂环境下的验证成本和不确定性还很高。
另一个瓶颈是 UI 设计稿规范。
如果设计稿不清楚标注“哪些是本次新增、哪些是动效、哪些有边界条件”，人类可以靠经验补全，Agent 往往会出现理解断层。
接下来会变好：设计稿也会 AI 友好化
随着 Claude Design 这类能力出现，设计输入会越来越结构化、语义化、可机器读取。
当设计稿本身开始面向 AI 组织，Agent 对需求识别的效率和准确率会明显提升。
到那时，Agent 不是只会“写代码”，而是能更完整地接管“从需求理解到交付验证”的链路。
写在最后：先当好养父
我说“我是 AI 的养父”，不是因为我比它聪明，
而是因为在这个阶段，我要负责两件事：
- 教它方法论。
- 喂它最新事实。
当这两件事做对了，AI 才能从“能生成代码”走向“能稳定交付”。
AI 的趋势无法阻挡。与其对抗，不如先当 AI 的爸爸，把它养成真正能打的交付 Agent。
在 AGI 来临之前，我们某种意义上都在燃烧自己，给 AI 提供养料。
这也正是“养父”这个角色最真实、也最残酷的一面。
