过去一年,开发者对 AI 编程的讨论从“它会不会写代码”转向“怎样让它稳定交付”。X 上关于 vibe coding、代理式开发和 Codex 类工具的长帖很多,它们共同指向一个事实:模型可以把想法迅速变成代码,但可交付的软件仍然需要上下文、边界、验证和审阅。
这篇文章把公开讨论与官方资料重新整理成一套个人开发者也能执行的流程。它不是某个帖子的复述,也不假装有神奇提示词。真正有用的不是一句口令,而是让 AI 在正确的约束里持续做小步工作。
先把 AI 从“聊天对象”变成“工程参与者”
很多失败的 AI 编程体验,起点就是把任务描述得像聊天:给它一个笼统目标,期待它自动知道代码库结构、产品意图、测试口径和发布风险。模型会尽力补全缺失信息,但补全本身就是风险来源。
更稳的方式是把 AI 当成一个工程参与者:它需要角色、输入、允许修改的文件、验收标准、不能触碰的边界,以及失败后该怎样恢复。OpenAI 的 Prompt engineering 文档也强调,编码任务应该给出明确角色、结构化工具使用方式、测试要求和输出格式。
提示词的重点不是“让模型更聪明”,而是把工程现场里那些默认知识显式写出来。
一条可复用的工作流
对个人网站、小工具、开源项目维护这类任务,我会把 AI 编程拆成六步:
- 先定义交付物:页面、脚本、修复、文档还是部署配置。
- 再限定上下文:相关目录、已有模式、不能改的文件、外部账号边界。
- 让 AI 先读再改:搜索文件、识别依赖、确认约定。
- 把大任务拆成可验证的小任务:一个页面、一个组件、一个脚本、一个测试。
- 每一步都保留验证命令:构建、lint、测试、链接检查或浏览器截图。
- 最后由人或更严格的模型审阅:看需求是否满足,看风险是否被遗漏。
这个流程的关键是“AI 可以快,但任务必须小”。当一个任务同时要求改前端、连数据库、重写认证、上线部署,模型就会被迫在大量隐含决策里猜。把任务切小后,它的优势才会出现:快速搜索、快速改动、快速运行验证,然后根据结果继续。
上下文比提示词更值钱
AI 编程真正消耗人的地方,不是敲代码,而是整理上下文。一个好上下文包通常包含:
- 目标:用户最终会看到或得到什么。
- 当前状态:哪些文件已经存在,哪些能力已经完成。
- 约束:技术栈、域名、部署平台、权限边界、版权要求。
- 验收:通过哪些命令或人工检查才算完成。
- 风格:现有页面的视觉语言、文案口吻、代码习惯。
社区里关于 代理式工程流程和 批量任务与并行代理的讨论提供了工作方式上的线索。本文进一步建议把验证放在每个任务的末尾:先让失败显形,再围绕证据修复。
不要把“能跑”当成“完成”
AI 生成的代码很容易给人一种已经完成的错觉。页面打开了,命令通过了,它还解释得很有条理。但交付标准应该再往前一步:
- 功能路径是否真的覆盖了用户要做的事。
- 错误状态、空状态、移动端、慢网络是否能接受。
- 依赖和外部 API 是否符合免费额度和权限边界。
- 生成内容是否有事实来源,是否误用了别人的长文或代码。
- 部署配置是否可重复,而不是只在当前机器碰巧成功。
这也是为什么本文所在的网站群采用纯静态结构:它把变量压到最低。没有数据库、没有用户登录、没有后台任务,就少了很多 AI 容易误判的状态。
个人开发者的实践建议
如果你正在用 AI 搭建个人网站或项目展示页,可以从一份简单的任务卡开始:
目标:新增一个项目详情页
输入:项目 README、截图、已有项目页模板
允许改动:public/projects/... 下的 HTML/CSS
禁止改动:部署脚本、其他项目页面
验收:本地构建通过,导航链接可点击,360px 和桌面宽度不溢出这类任务卡看起来朴素,但它能显著减少 AI 的猜测空间。等你需要更复杂的流程,再加入子任务、评审代理、自动化测试和部署检查。
资料来源
本文参考了 OpenAI 关于 Prompt engineering、Agents 和 Agents API 的官方资料,以及 X 上关于 vibe coding、代理式工程流程与 AI 编程实践 的公开讨论。X 链接只作为趋势线索,本文不复制原帖正文,也不声称其热度指标。