从写代码到用 智能体 部署怎么做？几位开发者的工作流迁移经验

Hacker News 社区里有一个提问帖，问的是从手写代码转到用智能体部署的工作流怎么搭 发帖人说自己过去一年一直在用 智能体驱动的编码方式，现在感觉必须在本地测完所有代码才能部署，因为他对智能体生成的代码没有足够信任感。这个问题在 HN 社区引起了大量讨论，回帖里有三种完全不同的工作流迁移路径。

第一条路径是测试先行派。一个叫 一个开发者 的开发者说，他解决信任问题的方式是先写测试再让 智能体写实现。具体流程是，他先用自然语言描述需求，然后自己手写测试用例，测试用例写完之后让智能体填实现。如果 智能体 的实现跑不过测试，就让智能体重新来。这种做法的好处是测试是人写的，智能体的输出质量有客观检验标准。坏处是写测试本身需要时间，对小项目来说开销偏大。

一个开发者 还提到一个细节。他说他一开始让 智能体 同时写测试和实现，后来发现 智能体会写一个很容易通过的测试来掩盖实现里的问题。把测试和实现分开，测试由人写，实现由 智能体 写，这个问题就消失了。这条经验对独立开发者很实用，多花 20% 时间写测试，省掉 80% 的 调试 时间。

第二条路径是分层信任派。一个叫 另一个开发者 的开发者把工作流分成三层。第一层是智能体写脚手架代码，比如 增删改查接口、数据模型、配置文件，这类代码结构化程度高，智能体出错概率低，他完全信任 智能体不做审查。第二层是业务逻辑代码，智能体写完之后他做一轮快速 审查，主要看逻辑分支是否覆盖完整，不做逐行审查。第三层是跟钱、权限、数据安全相关的代码，他不让 智能体碰，自己手写。

另一个开发者 说这种分层方式让他的开发速度提升了大约 3 倍，但不是所有项目都适合。他的项目是一个内部管理工具，业务逻辑不复杂，安全要求中等。如果做的是支付系统或者医疗数据平台，分层信任的阈值要调高，第二层和第三层都得自己来。

这条路径是是 持续集成 兜底派。一个叫 这位开发者 的开发者说，他不在本地测代码，直接让 智能体 写完 push 到 持续集成 跑。持续集成 里有完整的自动化测试套件，如果挂了就让 智能体 看 持续集成 日志修。他的逻辑是，本地测和 持续集成 测是等价的，既然 持续集成 有完整测试，在本地再跑一遍是浪费时间。

这位开发者 的做法争议最大，回帖里有人指出 持续集成 跑一次可能要 10-15 分钟，等 持续集成 结果再修比本地测更慢。这位开发者 的回应是，他同时开多个任务，一个任务在等 持续集成 的时候他做别的事，整体效率不比本地测低。但这种做法有一个前提，持续集成 测试套件必须非常完整，覆盖率和质量都要够高。如果测试套件本身有漏洞，持续集成 兜底就是空话。

这几条路径的共同点是，都不信任 智能体的原始输出，但信任的方式不同。测试先行派用人工测试兜底，分层信任派用审查兜底，持续集成 兜底派用自动化测试兜底。这几条路径都成立，但适用场景不同。

对独立开发者来说，一个开发者 的测试先行法最稳，适合一个人维护的小项目，测试写完之后 智能体写实现，产出质量可控。对小团队来说，另一个开发者 的分层信任法最实用，脚手架交给 智能体 省时间，核心逻辑人写保安全。对有完整 持续集成 流水线的团队来说，这位开发者 的 持续集成 兜底法效率最高，但前提是测试套件足够好。

帖子里还有一个值得注意的共识。所有人都同意，智能体的输出质量跟你给它的上下文质量正相关。你给它完整的需求文档、设计规范、代码规范，它的输出就好。你给它一句话需求，它的输出就是赌博。这意味着用 智能体写代码这件事，真正花时间的不是写 提示词，是写上下文。上下文写得越好，智能体的输出质量越高，你花在 审查 和 调试 上的时间越少。

对正在搭团队 AI 工作流的技术负责人来说，这个帖子里最有价值的经验不是哪条路径最好，而是这几条路径背后的共同逻辑。智能体 不是一个可以无脑信任的工具，也不是一个需要逐行审查的实习生。它是一个需要你设计信任边界的协作对象，边界设计得好，效率翻倍，边界设计得差，返工比手写还慢。

创业找资源，上乌鸦部落。