当 AI 开始真正参与项目开发
过去使用 ChatGPT 写代码，我们通常只考虑“Prompt 应该怎么写”。告诉 AI 想要什么，复制代码、运行、报错，再回来继续问。但 Claude Code、Codex、GitHub Copilot 等 Coding Agent 已经可以阅读仓库、搜索和修改文件、调用终端、运行测试并连续执行多个开发步骤。
于是问题从“怎样提问”变成了：如果 AI 真的可以操作整个项目，我们应该怎样管理它？很多人的第一反应，是把 TypeScript、数据库、API、安全、Git 等所有规则不断塞进一个越来越长的 AGENTS.md。然而，信息越多并不代表注意越准确，超长 Prompt 反而让错误更难定位。
PROSE 正是为此提出的一套 Coding Agent 工作环境设计方法。
深度拆解：什么是 PROSE？
PROSE 不是编程语言，也不是需要安装的软件框架，而是一套面向 Agentic Software Development 的工程纪律。
| 原则 | 含义 | 解决的问题 |
|---|---|---|
| P | Progressive Disclosure | AI 一次看到的信息太多 |
| R | Reduced Scope | 一次交给 AI 的任务太大 |
| O | Orchestrated Composition | Prompt 越写越复杂 |
| S | Safety Boundaries | AI 权限过大 |
| E | Explicit Hierarchy | 所有规则混在一起 |
让 Agent 在正确的时候，只看到正确的信息，只完成一个清晰的任务，并且只能操作它真正需要操作的东西。
下面以一个校园活动报名网站为例：用户可以登录、查看活动并报名，管理员可以查看报名名单。
P：不要让 AI 一次读完整个项目
Progressive Disclosure：渐进式披露
如果任务只是移动活动页上的报名按钮，Agent 真正需要的是 React 组件规范、UI 规范和当前页面代码，而不是数据库迁移、JWT、部署、日志和 API 权限。无关信息即使正确，也会稀释注意力。
把 AGENTS.md 从百科全书变成地图
根文件不必装下所有知识，只需要告诉 Agent：前端任务读 frontend.md，API 任务读 backend.md，数据库任务读 database.md，登录任务读 auth.md。知识在需要时才进入上下文。
Skill 也是按需加载
Skill 的 description 是能力索引。修改数据库时不必加载表单验证 Skill；创建报名表时，再加载其中的字段验证、错误提示和提交规范。渐进式披露的重点不是“告诉 AI 所有知识”，而是“告诉 AI 知识在哪里、何时读取”。
R：不要让 Agent 一口气开发整个功能
Reduced Scope：缩小任务范围
“实现活动报名功能”表面上是一件事，实际上包括数据结构、API、页面、认证、重复报名判断和测试。判断任务是否过大的简单问题是：Agent 完成以后，应该留下什么？如果无法用一句话描述交付物，就应该继续拆分。
- 设计报名数据结构，产出
registration_schema。 - 根据 Schema 创建报名 API，产出
registration.ts。 - 创建报名表，产出
RegistrationForm.tsx。 - 连接 API，修改表单与
api.ts。 - 验证正常报名和重复报名，产出
registration.test.ts。
Agent Debug 的黄金三步
修复“页面显示成功但数据库没有记录”时，把工作拆成 Diagnose → Implement → Validate：先只调查根因和证据；再根据诊断只修相关代码；最后真实运行测试，证明写入成功且重复报名被拒绝。三个阶段分别只思考“为什么坏”“怎么修”“真的修好了吗”。
O：不要试图写出“究极 Prompt”
Orchestrated Composition：编排式组合
超级 Prompt 把代码、数据库、测试、安全、UI、API、输出和 Git 规则浇筑成一整块水泥。一旦 Agent 出错，很难判断是哪一条规则、哪一层上下文出了问题。
更好的做法是把能力拆成积木：项目规则 + 前端规则 + 数据库规则 + Skill + Agent 角色 + 当前任务。AGENTS.md 回答“什么时候用什么”，Instructions 回答“项目有什么规则”，Skill 回答“这类任务怎么做”，Docs 描述“项目本身是什么”，Prompt 只负责组合这些模块完成本次任务。
例如项目可以包含根 AGENTS.md、按领域拆分的 instructions/、可复用的 skills/、任务模板 prompts/ 与项目知识 docs/。Prompt 不再承担保存全部知识的责任，而负责调度已有模块。
S：不要相信 AI 永远不会犯错
Safety Boundaries：安全边界
真正的问题不是“AI 会不会犯错”，而是“如果它犯错，最多能破坏多少东西”。在 Prompt 里写“请谨慎操作”，无法替代文件、终端、数据库、Secret、删除与部署权限的真实边界。
不同 Agent 应该拿不同的钥匙
- Code Writer：可读取和修改
src、搜索代码并运行测试，但不能部署生产、读取 Secret、删除数据库或修改 CI/CD。 - Reviewer：可读代码、搜索并运行检查，但职责是发现问题，不应直接修改代码。
- Test Runner：可以运行测试，却不能为了让测试通过而删除失败测试或修改生产代码。
STOP：决定必须留给人类
删除数据库表、修改认证、公共 API、权限系统或部署生产，都应触发 STOP Gate。Agent 必须先说明原因、影响范围和迁移需求，然后等待人类确认。
“应该通过”不等于“已经通过”
可靠流程要求真的执行 npm test，并报告诸如“23 passed, 1 failed”的现实结果。测试、API、文件系统和命令输出，是 Agent 判断现实的锚点：不仅觉得自己做对了，还要证明自己做对了。
E：为什么一个项目不应该只有一个 AGENTS.md？
Explicit Hierarchy：显式层级
规则应跟着代码位置生效。根目录规定 TypeScript、测试、Secret 和 Commit 规则；frontend/AGENTS.md 规定 React、PascalCase 与 Loading；backend/AGENTS.md 规定 API Response、输入验证与 Repository；backend/auth/AGENTS.md 再增加 Token 不入日志、认证修改必须 STOP、Cookie 必须 HttpOnly。
修改 backend/auth/session.ts 时，Agent 获得 Global + Backend + Auth 规则；修改 frontend/Button.tsx 时，则不需要考虑 Token 和 Session。就像国家法律、地方规定和公司制度，层级让规则的作用范围变得明确。
从 Prompt Engineering 到 Agent Engineering
- P：Agent 应该看到什么？
- R：Agent 这一次应该做多少？
- O：规则和能力怎么组合？
- S：Agent 最多能够做什么？
- E：哪里的代码应该遵守哪些规则？
五项原则依次控制信息、任务、能力、权限和规则作用范围。此时我们管理的不再是一条 Prompt，而是一整套 Agent 工作环境。
实战指南：初学者应该从哪里开始？
个人项目的第一版不需要十几个 Agent 和几十个 Skill。一个根 AGENTS.md，配合 docs/、instructions/ 和 src/ 就足够开始。
- 什么时候读什么：前端、后端、数据库任务分别路由到对应说明。
- 什么时候必须问人：删除文件、修改 Schema、认证、公共 API 或部署生产时停止。
- 怎样证明完成：运行相关测试、报告真实结果、列出修改文件和遗留问题。
完成这三件事，就已经比“一个拥有全部权限、背着几千字超级 Prompt 的万能 Agent”更接近可维护的工程系统。
真正的变化：我们开始设计 AI 的工作环境
Prompt Engineering 关注“我要怎么告诉 AI”；Agent Engineering 关注 AI 能看到什么、可以做什么、何时加载信息、任务应该多大、哪些决定必须交还人类，以及如何验证结果。
当 AI 从回答问题的助手变成能够修改代码、运行工具甚至影响生产环境的执行者，我们不能再只依赖一句“请认真一点”。真正可靠的系统由 Context + Rules + Skills + Agents + Tools + Permissions + Validation 共同组成。
下一阶段值得学习的，不是如何让 AI 写更多代码，而是如何让 AI 在一个可控、可验证的系统中工作。
资料说明
本文关于 PROSE 五项原则的概念框架，参考 The Agentic SDLC Handbook Chapter 13 “The PROSE Constraints”。PROSE 原作者将其定位为面向 Agentic Software Development 的工程纪律，而非正式行业标准。文中的校园活动报名网站、Agent 角色及开发案例均为重新设计的教学案例。