AI Coding 已经过了只拼 prompt 的阶段
过去一年，很多开发者讨论 AI Coding，重点都放在 prompt 上。比如怎么写提示词让 AI 生成更好的代码，怎么让 AI 一次性完成整个功能，怎么让 Claude Code、Cursor、Codex、Copilot 更听话，怎么让 AI 少犯错。
这些问题当然重要，但它们已经不是 AI Coding 的核心问题了。
真正的问题变成了：当 AI 已经能写大量代码时，我们如何保证这些代码可控、可测、可维护、可上线？
也就是说，AI Coding 的下一步，不是更花哨的 prompt，而是更清晰的工程约束。
OpenAI 对 Codex 的介绍中提到，Codex 已经可以在云端沙箱中处理写功能、修 bug、回答代码库问题、提出 PR 等任务；GitHub Copilot 的官方实践也强调，AI coding agent 更适合处理范围清晰、可拆解、可 review 的任务，而不是模糊地“帮我做完整项目”。
这说明 AI 编程正在从聊天式生成代码进入工程化协作阶段。
prompt 技巧为什么不够了
prompt 技巧解决的是“如何让 AI 输出更接近我的意图”。
但工程开发解决的是另一个问题：如何让系统在多人、多版本、多环境、多风险下稳定运行。
一个好的 prompt 可能让 AI 生成一段漂亮的代码，但它无法自动保证代码是否符合项目架构、是否破坏已有功能、是否有测试覆盖、是否存在安全漏洞、是否符合团队规范、是否能在生产环境稳定运行、是否方便三个月后继续维护。
这就是为什么很多人用 AI Coding 初期感觉很爽，后期却越来越痛苦。
项目刚开始时，AI 能快速生成页面、接口、数据库模型和业务逻辑。过一段时间后，文件结构越来越乱，同一个功能出现三种实现方式，AI 修改一个 bug 又引入两个新 bug，旧代码没人敢动，测试缺失，部署靠运气，每次改需求都像在拆炸弹。
这不是 AI 不够聪明，而是你没有给它工程边界。
从指令驱动转向约束驱动
早期 AI Coding 是指令驱动的。你说“帮我写一个登录功能”，AI 就写一个登录功能。你说“帮我加一个支付页面”，AI 就加一个支付页面。你说“帮我修复这个报错”，AI 就尝试修复报错。
这种方式适合小任务，但不适合长期项目。因为每一次对话都是局部的，AI 很容易只解决眼前问题，而忽略系统整体。
下一阶段的 AI Coding 应该是约束驱动的。你不只是告诉 AI 要做什么，还要告诉它什么不能做、哪些文件不能改、哪些接口必须保持兼容、哪些测试必须通过、哪些安全规则不能违反、哪些代码风格必须遵守、哪些业务逻辑必须先确认、什么时候必须停止并询问人类。
prompt 是一次性指令，工程约束是长期规则。prompt 让 AI 开始工作，工程约束让 AI 不乱工作。
工程约束到底是什么
工程约束不是一句“请写高质量代码”。它是一套明确、可执行、可检查的规则。
OpenAI 的 Codex 最佳实践中特别提到，新手使用 coding agent 时应默认保持审批和沙箱权限严格，只在可信任务中逐步放宽权限。
这正是工程约束的典型思路：不是默认相信 AI，而是默认限制 AI。
- 需求约束：防止 AI 误解目标
- 架构约束：防止 AI 乱改结构
- 文件约束：限制 AI 修改范围
- 测试约束：保证修改可验证
- 安全约束：防止引入漏洞
- 权限约束：控制 AI 能执行什么
- 交付约束：保证代码可 review、可合并、可回滚
第一层约束：需求必须可拆解
很多 AI Coding 失败，是从需求描述太大开始的。
“帮我做一个完整的 SaaS 系统”“帮我开发一个类似 Notion 的产品”“帮我做一个电商平台，包括前端、后端、支付、后台和部署”，这些 prompt 看起来很酷，但工程上很危险。
AI 可能会生成一堆看似完整的代码，但里面充满隐性问题。
更好的方式是把需求拆成可执行任务。GitHub Copilot 的官方最佳实践也强调，交给 coding agent 的 issue 应该范围清晰，并鼓励先研究、规划、迭代，再进入 PR 阶段。
换句话说，AI Coding 不是把一句大需求丢给 AI，而是把工程任务拆成可以验证的小闭环。
先设计用户注册和登录模块，不写代码，只输出数据表、接口、状态流转和安全注意点。
根据确认后的接口设计，实现注册 API，只允许修改 auth 目录下的文件。
为注册 API 添加单元测试，覆盖邮箱重复、密码过短、数据库异常三个场景。
运行测试，如果失败，只修复相关测试，不允许改动接口定义。第二层约束：架构必须提前写下来
AI 最容易犯的一个问题，是为了完成当前任务而破坏整体架构。
比如你的项目本来有 features、shared、lib、api、components 等目录，AI 为了快速实现一个功能，可能又新建 utils、helpers、common、services、new-api、temp。最后项目里到处都是重复文件。
解决方法很简单：把架构约束写成文档。例如在项目根目录放一个 ARCHITECTURE.md，里面写清楚目录规则、模块边界、公共类型修改规则和禁止新增的模糊目录。
这类文档看起来普通，但它是 AI Coding 的护栏。没有护栏，AI 会以最快方式完成任务；有了护栏，AI 才会以符合项目规则的方式完成任务。
# Architecture Rules
1. 所有业务功能必须放在 src/features 下。
2. 通用组件必须放在 src/shared/components。
3. API 请求只能通过 src/lib/apiClient.ts 发起。
4. 不允许在组件中直接访问数据库。
5. 不允许新增 utils、helpers、common 这类模糊目录。
6. 新增模块必须包含 index.ts 导出。
7. 修改公共类型前必须说明影响范围。第三层约束：文件修改范围必须明确
一个很实用的原则是：每次只让 AI 修改它应该修改的文件。
比如你要修复登录按钮样式，就不要让 AI 扫描整个项目并自由修改。
对于 coding agent 尤其重要。因为 agent 不只是回答问题，它可能真的会读文件、改文件、运行命令，甚至提交 PR。Codex、Copilot coding agent 这类工具都在朝这个方向发展。
AI 能做得越多，边界就越重要。
请只修改以下文件：
- src/features/auth/LoginForm.tsx
- src/features/auth/LoginForm.module.css
目标：
修复移动端按钮宽度溢出问题。
限制：
- 不允许修改登录逻辑
- 不允许修改 API 请求
- 不允许新增依赖
- 不允许重命名组件第四层约束：测试是 AI Coding 的刹车系统
很多人用 AI Coding 时，只关心代码是否生成成功，却不关心测试是否存在。这很危险。
因为 AI 生成的代码常常看起来合理，但边界情况可能是错的。尤其是权限、金额、状态流转、异常处理、数据一致性这些地方，肉眼很难一次看出来。
AI Coding 的基本规则应该是：没有测试的 AI 代码，不算完成。
测试的意义不只是发现 bug，更是给 AI 提供反馈回路。没有测试时，AI 只能猜；有测试时，AI 可以根据失败信息修正。
这就是从 prompt 技巧到工程约束的关键转变：让 AI 面对机器可验证的标准，而不是只面对人类模糊的满意度。
- 后端测试：正常路径、参数为空、参数非法、权限不足、外部服务失败、重复请求
- 前端测试：初始渲染、loading 状态、error 状态、空数据状态、用户点击提交
第五层约束：安全规则必须显式声明
AI 不会天然知道你的安全红线。你必须明确告诉它哪些事情不能做。
这些规则应该写进项目文档，而不是每次靠记忆补充。
AI Coding 在安全上最大的问题，不是它一定会写出漏洞，而是它可能写出看起来能运行的不安全代码。
比如为了方便调试，把用户 token 打印到 console；为了快速实现搜索，拼接 SQL；为了绕过类型错误，使用 any；为了修复 CORS，直接允许所有来源；为了完成上传，忽略文件大小限制；为了通过测试，跳过权限判断。
安全约束的目的，就是让 AI 在动手之前知道哪些路不能走。
# Security Rules
1. 不允许把 API Key 写入代码。
2. 不允许在日志中输出 token、password、secret。
3. 所有用户输入必须校验。
4. SQL 查询必须使用参数化查询。
5. 文件上传必须限制类型和大小。
6. 管理员接口必须检查权限。
7. 错误信息不能暴露数据库结构。
8. 不允许关闭 TypeScript 严格检查。
9. 不允许使用 eval。
10. 不允许引入未维护或高风险依赖。第六层约束：权限和执行环境要受控
当 AI 只是聊天机器人时，风险主要是回答错。当 AI 变成 coding agent 时，风险变成执行错。
它可能会删除文件、修改配置、安装依赖、运行脚本、访问环境变量、改数据库迁移、推送代码、创建 PR。
所以你需要控制 AI 的权限。OpenAI Codex 的最佳实践也建议默认保持沙箱和审批严格，再根据任务可信度逐步放宽。
不要因为 AI 很聪明，就给它生产环境钥匙。
- 解释代码：只读
- 修改单文件：限制目录写入
- 生成测试：限制测试目录
- 安装依赖：必须人工确认
- 数据库迁移：必须人工确认
- 删除文件：默认禁止
- 部署生产：禁止自动执行
- 修改权限系统：必须人工 review
第七层约束：AI 产出的代码必须走 PR 流程
很多独立开发者没有 PR 习惯，直接在主分支上让 AI 改代码。这在小 demo 中没问题，但在真实项目中很危险。
哪怕你是一个人开发，也建议走分支、检查、review、合并的流程。PR 的价值不只是团队协作，而是给你一个停下来检查的节点。
这能把 AI 输出从代码片段变成可审查的工程交付。
- 为每个 AI 任务创建分支
- AI 只在分支上修改
- 自动运行 lint、typecheck、test
- 生成变更说明
- 人类 review
- 合并前再次运行测试
- 保留回滚路径
## Changes
- 修改了哪些文件
- 实现了什么功能
## Tests
- 运行了哪些测试
- 是否通过
## Risks
- 可能影响哪些模块
- 是否有兼容性风险
## Rollback
- 如果出问题如何回滚把一句 prompt 改成工程任务书
假设你要让 AI 实现用户修改邮箱功能。普通 prompt 可能是“帮我实现用户修改邮箱功能”。这太宽泛。
工程化 prompt 应该写清楚背景、允许修改范围、禁止修改范围、功能要求、安全要求、测试要求和交付输出。
这就是下一代 AI Coding 的基本形态。不是一句“帮我写代码”，而是一份小型工程任务书。
请实现用户修改邮箱功能。
背景：
- 项目是 Next.js + Prisma + PostgreSQL
- 用户认证已存在
- 当前用户信息来自 getCurrentUser()
允许修改：
- src/features/account/email/
- src/app/api/account/email/route.ts
- tests/account/email.test.ts
禁止修改：
- 不允许修改 auth 核心逻辑
- 不允许修改 Prisma schema
- 不允许新增依赖
- 不允许修改其他 account 功能
功能要求：
1. 用户必须登录
2. 新邮箱不能为空
3. 新邮箱必须符合邮箱格式
4. 新邮箱不能与当前邮箱相同
5. 新邮箱不能已被其他用户使用
6. 修改成功后返回 updated user profile
7. 所有错误必须返回统一错误格式
安全要求：
1. 不允许在日志中输出邮箱修改 token
2. 不允许绕过权限判断
3. 数据库查询必须使用 Prisma API
测试要求：
1. 未登录时返回 401
2. 邮箱格式错误返回 400
3. 邮箱重复返回 409
4. 正常修改返回 200
5. 数据库异常返回 500
完成后请输出：
- 修改文件列表
- 测试说明
- 潜在风险为什么约束会让 AI 更强
很多人误以为，约束越多，AI 发挥越差。实际上正好相反。
工程约束会让 AI 更强，因为它减少了 AI 的猜测空间。
没有约束时，AI 要猜用什么架构、改哪些文件、是否要新增依赖、错误怎么处理、测试写到什么程度、安全要求是什么、哪些行为是禁止的。
有约束时，AI 只需要在明确边界内完成任务。
这就像管理一个新人。你不能只说“把项目做好”，你要告诉他目标、边界、标准、验收方式和风险点。AI coding agent 也是一样。
越强的 agent，越需要清晰规则。越复杂的项目，越需要工程约束。越接近生产环境，越不能只靠 prompt 感觉。
成熟 AI Coding 工作流的六步
一个成熟的 AI Coding 工作流，可以分成六步：Spec、Plan、Execute、Verify、Review、Ship。
Spec 阶段先写规格，不先写代码，包括用户故事、输入输出、状态变化、错误情况、权限规则、数据模型和验收标准。
Plan 阶段要求 AI 在改代码前先说明要改哪些文件、为什么改这些文件、是否需要新增依赖、是否影响已有功能、测试怎么写。
Execute 阶段限制目录范围、文件范围、命令范围、依赖范围和数据库操作范围。
Verify 阶段运行 lint、typecheck、test、build 等机器验证。不同项目命令不同，但原则一样：必须有机器验证。
Review 阶段人类审查权限、支付、数据删除、数据迁移、安全配置、生产部署、用户隐私和核心业务逻辑。Ship 阶段小步上线，可监控，可回滚。
独立开发者从四个文件开始
如果你是一个人开发者，不需要一开始就搞复杂流程。你可以从四个文件开始：PROJECT.md、ARCHITECTURE.md、SECURITY.md、AI_RULES.md。
PROJECT.md 写项目目标、技术栈、主要模块。ARCHITECTURE.md 写架构规则和目录规范。SECURITY.md 写安全红线。AI_RULES.md 写 AI 工作规则。
这四个文件就是你的 AI 工程护栏。它们不复杂，但非常有效。
# Project
这是一个面向独立创作者的订阅制内容平台。
Tech Stack:
- Next.js
- TypeScript
- PostgreSQL
- Prisma
- Stripe
Core Modules:
- Auth
- Subscription
- Content
- AdminAI_RULES.md 应该写什么
AI_RULES.md 不需要写成百科。它只需要写会改变 AI 行为的规则。
这些规则要足够具体，让 AI 知道什么时候能继续、什么时候必须停下来问人。
# AI Rules
1. 改代码前必须先输出计划。
2. 不允许一次修改超过 5 个文件，除非得到确认。
3. 不允许新增依赖，除非说明原因。
4. 不允许删除文件，除非得到确认。
5. 完成后必须说明测试结果。
6. 遇到不确定需求必须停止并提问。
7. 不允许修改 .env 文件。
8. 不允许直接操作生产数据库。团队落地要把责任写清楚
如果是团队使用 AI Coding，则需要更正式的规则。
团队还要明确一个原则：AI 生成代码，不等于免除开发者责任。
谁发起任务，谁负责验收。谁合并 PR，谁负责质量。谁上线功能，谁负责结果。
AI 可以参与开发，但不能成为责任主体。
- 统一 AI 使用规范
- 代码生成范围规则
- PR 模板
- 自动测试要求
- 安全 review 清单
- 依赖引入规则
- Agent 权限分级
- 生产环境禁区
- 事故回滚流程
AI Coding 的未来会更工程
很多人想象 AI Coding 的终点是：我说一句话，AI 自动完成所有软件。
这可能会在某些低风险场景中发生，但对真实工程来说，未来不会是无约束自动化。
恰恰相反，AI 越强，工程约束越重要。因为当 AI 能写十行代码时，错误影响有限；当 AI 能改一整个模块时，错误影响扩大；当 AI 能创建 PR、运行命令、连接服务时，错误可能直接进入生产链路。
所以 AI Coding 的下一步，不是让 AI 更自由，而是让 AI 在正确边界内更高效。
过去优秀开发者擅长写代码、调 bug、读文档、设计架构。未来优秀开发者还要擅长写规格、设边界、建验证、管 agent、审查 AI 输出、设计人机协作流程。
prompt 技巧仍然有用，但它只是入口。真正的竞争力，是把 AI 编程变成稳定、可控、可复用的工程系统。
FAQ：常见问题
下面这些问题，可以作为你升级 AI Coding 工作流前的检查入口。
结语：做能约束 AI 的工程师
AI Coding 的第一阶段，比的是谁更会写 prompt。AI Coding 的下一阶段，比的是谁更会设计工程约束。
会 prompt，你可以让 AI 写出代码。会约束，你才能让 AI 写出可上线、可维护、可负责的代码。
这就是 AI Coding 的真正升级方向：从一句话生成，走向规格化任务；从自由发挥，走向边界控制；从代码片段，走向 PR 交付；从人工感觉，走向自动验证；从“AI 帮我写”，走向“AI 在工程系统里协作”。
未来的开发者，不一定要亲手写每一行代码，但必须知道系统应该如何被构建、验证和约束。
因为软件最终不是靠 prompt 运行的。软件靠工程运行。