这篇内容讨论的不是“怎样让模型一次把代码写对”，而是怎样把开发过程改造成一个可验证的 Agent 闭环：Agent 能使用浏览器、终端和外部 API，完成实现、运行、观察结果、修正和再次验证。它最值得借鉴的地方，是把人的工作从反复搬运代码，转为设定目标、提供受控环境并验收最终结果。
从聊天式开发切换到执行式开发
传统聊天式流程通常是：人在聊天窗口描述需求，复制模型输出到项目中，自己运行测试，再把报错贴回去。这条链路的问题不只是慢，还容易在多轮复制中丢失环境状态。
原作者强调的关键变化是“让 Agent 自己测试最终产物”。Agent 不再只交付一段代码，而是通过工具直接接触目标环境：网页项目可在 Chromium 中打开和调试；命令行项目可在终端构建、运行并读取错误；有图形界面的程序则可借助截图和界面标识确认状态。
真正的交付单位因此从“代码片段”变成了“经过验证的结果”。
一套可复用的执行流程
1. 先把验收条件写清楚
不要只说“做一个功能”，应同时说明输入、预期输出、失败表现和验证方式。例如网页功能至少要定义目标页面、关键交互和成功状态；命令行工具要明确构建命令、示例参数、退出状态以及输出中应出现的内容。
验收条件越具体，Agent 越容易自己判断下一步应该修代码、补依赖，还是重新运行测试。
2. 给工具，不直接给无限权限
根据任务只开放必要能力：网页调试使用浏览器，编译和测试使用受限终端，调用 Cloudflare、GitHub 等服务时使用范围受限的 API 凭据。工作目录、执行时间、输出大小和网络访问范围都应设边界。
密钥不要写进提示词或仓库。需要账号登录时，可以先由 Agent 打开共享的图形环境，再由人完成登录，之后把已经登录的会话交回 Agent。这样既保留调试连续性，也不必把密码交给模型。
3. 让 Agent 按“执行—观察—修正”循环
一次生成代码后立即运行对应检查：前端打开页面并检查交互；后端执行构建、测试和示例请求；GUI 程序通过截图确认控件和状态。每轮都保存命令、结果和错误摘要，避免只凭自然语言判断“应该可以”。
若连续多轮没有进展，应停止并回到需求或环境层排查，而不是无限尝试。
4. 选择便于验证和交付的技术栈
原帖给出的一个实践方向是 HTML 前端配合 Go 后端：浏览器方便自动检查前端，Go 又便于在 Linux 开发环境中交叉编译出 Windows 可执行文件。这里的重点不是固定采用某种语言，而是优先选择 Agent 能运行测试、目标机器也容易部署的组合。
5. 把成功过程固化
任务完成后，让 Agent 把稳定步骤整理成脚本、测试命令或检查清单。下次相似需求不必重新解释全部过程，只需复用脚本并调整参数。脚本仍要接受代码审查，并记录依赖版本和回退方式。
怎样判断闭环是否真的有效
可以用五项检查：产物能否从干净环境构建；核心场景是否自动验证；失败时是否保留可定位信息；高影响动作是否有人确认；同一流程能否重复运行并得到一致结果。
原作者提到这些实例并未依赖最昂贵的模型。这更适合作为一个经验观察：当工具、反馈和验收条件足够清楚时，模型价格未必是决定结果的唯一因素；但不同任务的复杂度和风险仍需分别评估。
原作者：crazypeace（ǝɔ∀ǝdʎz∀ɹɔ 👽）
原帖：https://linux.do/t/topic/2708835