1. 引言：可信交付，而不是生成速度

AI Coding Assistant 的价值不在于一次输出多少行代码，而在于能否持续交付可理解、可测试、可回滚、可审查的变更。对于中高级开发者，真正昂贵的不是少写几十行代码，而是错误设计进入主干、验证不足导致缺陷逃逸，或者一个拥有过大权限的 Agent 修改了不该修改的系统。

因此，本文把 AI 编程助手放进软件工程的完整约束中：人负责目标、边界和风险判断，Agent 负责探索、实现和机械化执行，工具负责提供确定性的反馈，代码审查负责最终的责任确认。这个闭环适用于使用 Codex、Cursor、Claude Code 或 GitHub Copilot 的个人开发者，也适用于需要统一规范的工程团队。

本文的目标不是比较哪个产品“最强”，而是回答五个问题：

  • 如何准备一个 Agent 真正能工作的仓库环境？
  • 如何把模糊需求变成可执行、可验收的任务？
  • 如何让每次修改都经过可重复的验证？
  • 如何管理上下文，让长期任务可以可靠交接？
  • 如何在提高效率的同时控制提示注入、权限和责任风险？

2. 心智模型：低上下文、高执行力

2.1 Agent 不是读心者

现代编码 Agent 可以搜索文件、调用工具、修改代码、运行测试，并根据结果继续迭代。但它仍然主要根据当前上下文推断意图。上下文缺失时，模型可能生成看似合理却不符合仓库约定的实现；上下文过多时，重要约束可能被噪声淹没。

一个实用的心智模型是：

低上下文、高执行力：给 Agent 足够的目标、边界和验证入口，不要把整个组织的知识库无差别塞进每次会话。

“低上下文”不是少给信息，而是只提供对当前决策有影响的高信号信息；“高执行力”也不是授予无限权限，而是让 Agent 在明确边界内完成搜索、编辑和验证。

2.2 生成可以概率化，验收必须确定化

代码生成本质上带有概率性：同一任务可能得到不同实现，模型也可能误解隐含约束。验收则必须尽量确定化：

环节 可以接受的概率性 必须确定的结果
设计候选 多个方案、多个权衡 选择理由和不变量
实现 实现路径可以不同 接口、行为和约束满足要求
测试 测试策略可以补充 命令可执行、结果可复现
审查 可以借助 AI 找问题 人类确认风险和最终责任

这意味着“代码看起来正确”不等于“任务完成”。至少要有一个能失败的检查：编译、静态检查、单元测试、集成测试、E2E、截图对比、性能基准，或者硬件上的实际验证。

3. 可工作的环境：让仓库成为执行系统

3.1 构建和测试必须可执行

在让 Agent 修改代码前，先确认仓库能提供清晰反馈：

  1. 安装依赖的方式明确，版本来源可追踪。
  2. 构建、格式化、静态检查和测试都有稳定入口。
  3. 测试失败时能返回有用的错误，而不是只打印“failed”。
  4. 本地环境与 CI 的关键差异已经记录。
  5. 需要凭据、服务或硬件的测试有安全的替代模式。

下面是一份与工具无关的任务前检查。命令和注释使用英文，便于直接复制到常见终端：

1
2
3
4
5
6
7
# Confirm the repository has the expected entry points.
test -f package.json || test -f go.mod || test -f pyproject.toml

# Run the repository's documented verification commands.
make lint
make test
make build

如果仓库不使用 make，应在规则文件中写出真实命令，而不是让 Agent 猜测。首次执行时先记录基线结果：哪些检查当前已失败、哪些服务不可用、哪些测试需要额外环境。否则，Agent 可能把原有失败误认为本次修改造成的问题。

3.2 提供仓库地图

仓库地图不需要复制所有文件内容，只需告诉 Agent 从哪里开始寻找答案：

1
2
3
4
5
6
7
Repository map:
- src/: production application code
- tests/unit/: fast isolated tests
- tests/integration/: tests requiring external services
- docs/architecture.md: current architecture decisions
- scripts/verify.sh: canonical local verification entry point
- .github/CODEOWNERS: ownership and review boundaries

地图应随着目录结构变化更新。它的作用是减少无目的搜索，并指向权威文件，而不是制造第二份容易过期的架构文档。

3.3 AGENTS.md、工具规则和 Skills 分层

不同类型的指导应放在不同层级：

  • 全局规则：个人偏好、低风险的审批习惯、通用输出风格。不要放入项目特有架构。
  • 仓库规则：构建命令、目录边界、架构不变量、版本控制边界、何时引用哪份文档。
  • 路径规则：只对特定目录生效，例如数据库迁移、移动端 UI 或安全敏感模块。
  • Skills：按需加载的重复流程，例如调试、恢复、总结、发布检查。Skill 应描述可执行步骤和验证方式。
  • MCP 或外部工具：连接缺陷系统、知识库、文档系统等外部上下文，但返回内容必须按不可信输入处理。

一个精简的 AGENTS.md 可以这样写：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Repository Instructions

## Verify

- Run `./scripts/verify.sh` after every implementation change.
- Run `./scripts/verify.sh --full` before requesting review.

## Boundaries

- Keep public API behavior backward compatible unless the task says otherwise.
- Do not edit generated files by hand.
- Do not access production data or commit credentials.

## Architecture

- Put domain logic in `src/domain/`.
- Keep HTTP handlers thin and test them through the service boundary.
- Read `docs/architecture.md` only when changing cross-module behavior.

## Git

- Inspect the complete diff before declaring the task complete.
- Do not commit or push unless the user explicitly requests it.

规则要短、稳定、可验证。全局规则与仓库规则分离，可以避免把个人习惯误当成团队约束；规则与状态文档也应分离，避免一次任务产生的临时结论污染长期指导。

4. 高质量任务模板

4.1 Goal/Context/Constraints/Done When/Non-goals

每次会话尽量只处理一个可交付任务。推荐使用以下五段式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Goal:
Add idempotency protection to the payment creation endpoint.

Context:
- Endpoint: src/payments/http/create_payment.ts
- Service: src/payments/application/create_payment.ts
- Existing request ID middleware: src/platform/request_id.ts
- Relevant tests: tests/integration/payments/create_payment.test.ts

Constraints:
make lint

Done When:
- Repeated requests with the same valid key return the original result.
- Conflicting payloads for the same key return a deterministic 409.
- Unit and integration tests pass.
- ./scripts/verify.sh passes.
- The final report lists changed files, checks, and remaining risks.

Non-goals:
- Redesign payment authorization.
- Add a new cache provider.
- Refactor unrelated error handling.

这个模板的关键不是英文格式本身，而是把隐含假设显式化。Context 指向高价值文件，Constraints 保护架构和安全边界，Done When 让 Agent 有自我校正的依据，Non-goals 防止范围膨胀。

4.2 模糊提示与改进提示

模糊提示：

1
Fix the payment API and add tests.

它没有说明哪个行为错误、兼容性边界是什么，也没有定义测试完成条件。改进后：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Goal:
Fix duplicate payment creation when the client retries after a timeout.

Context:
- Trace the request from `src/payments/http/create_payment.ts` to the persistence adapter.
- Read the existing retry and error tests before editing.
- Use the current request ID or idempotency abstraction if one exists.

Constraints:
- Keep the public response schema unchanged.
- A successful retry must not create a second charge.
- Do not weaken authentication or validation.
- Do not modify unrelated modules or generated files.

Done When:
- Add a regression test that reproduces the duplicate-creation case.
- Add tests for a new key, a repeated key, and a conflicting payload.
- Run the focused tests and then `./scripts/verify.sh`.
- Explain any behavior that remains dependent on the payment provider.

Non-goals:
- Replace the payment provider.
- Change retry policy for unrelated endpoints.

改进提示不需要规定每一行代码怎么写。它应规定问题、证据、边界和验收，让 Agent 在局部设计上发挥作用。

5. 复杂任务先规划：只读探索、垂直切片、审批点

5.1 先探索，再规划

大型功能直接进入编辑阶段，常见结果是“局部实现正确、整体方向错误”。先使用只读探索回答：

  • 当前行为从哪里进入、经过哪些边界、在哪里持久化？
  • 哪些模块是权威实现，哪些是生成物或兼容层？
  • 现有测试覆盖了什么，缺少什么？
  • 哪些架构决策会影响多个团队或服务？
  • 哪些操作需要人工审批？

探索阶段不应修改文件。让 Agent 输出证据、候选方案、风险和待确认问题；如果架构不确定，可以让多个独立 Agent 分别调查并提出方案，实施前比较它们的证据，而不是让多个 Agent 同时编辑同一组文件。

5.2 垂直切片优于大爆炸实现

把“大功能”拆成可运行的垂直切片，每片穿过完整链路：

  1. 定义一个最小用户场景。
  2. 修改接口、领域逻辑和持久化的最小集合。
  3. 增加从入口到关键结果的测试。
  4. 运行验证并记录决策。
  5. 再扩展下一个场景。

每个会话只承载一个主要任务。重复出现的实现模式应加入任务列表或团队模板，而不是依赖模型在长会话中记住。

5.3 在高风险动作前设审批点

至少在以下节点停下来确认：

  • 方案会改变公共 API、数据模型或权限模型。
  • 需要删除数据、迁移生产数据或修改部署策略。
  • Agent 请求新增网络、文件系统或云平台权限。
  • 测试结果与预期不一致，但 Agent 想跳过检查。
  • 需要合并到受保护分支或发布制品。

审批点不是拖慢流程，而是把不可逆风险放在人类最容易发现的时刻。

6. Explore→Plan→Implement→Verify→Review→Iterate 工程闭环

一个可复用的闭环如下：

1
2
3
4
5
6
7
8
9
10
11
12
Explore
  ↓ evidence, current behavior, unknowns
Plan
  ↓ design, file scope, verification plan, approval points
Implement
  ↓ smallest vertical slice
Verify
  ↓ deterministic checks and evidence
Review
  ↓ complete diff, security, ownership, maintainability
Iterate
  └─ fix findings or stop with explicit residual risk

Explore

使用语义导航、符号引用、测试搜索和版本历史定位入口。不要只依赖文件名匹配；确认调用关系和数据流。

Plan

计划应包含变更文件范围、关键不变量、测试策略、风险和不做的事情。计划不是实现的替代品，而是让实施前的分歧暴露出来。

Implement

先做最小变更，保持每一步都能编译或至少能执行局部检查。不要在一次任务中顺便清理无关代码，因为额外 diff 会增加审查和回滚成本。

在动手前建立可恢复边界：使用独立分支或 worktree 隔离实验，并在每个可验证切片后保留 Git checkpoint。checkpoint 必须对应真实通过的检查；不要把未经验证的中间状态当成稳定恢复点。对仍以 Perforce 等系统为权威版本库的项目，也可以在本地使用 Git 层辅助 Agent 查看 diff、建立分支和回滚实验，但最终提交仍遵守团队的权威流程。

Verify

先运行最快的反馈，再运行完整检查。失败时读取真实输出，判断是环境问题、基线问题还是本次回归，不要用“测试不稳定”作为默认解释。

Review

审查完整 diff，而不是只看 Agent 的总结。检查新增文件、重命名、删除、生成文件、配置和权限变化。重点关注错误路径、边界输入、日志、秘密、并发和兼容性。

Iterate

根据验证和审查结果继续小步修复。如果 Agent 开始反复修改同一处、不断引入新问题，保存已经验证的状态和开放问题，重新开始一个会话通常比继续堆叠陈旧上下文更可靠。

7. 测试与验证：从“能跑”到“可证明”

7.1 分层验证

推荐按成本和反馈速度排序：

  1. 格式化和静态检查：捕获明显的类型、风格和依赖问题。
  2. 单元测试：验证纯逻辑、边界条件和错误映射。
  3. 集成测试：验证数据库、队列、外部服务适配器之间的契约。
  4. E2E 测试：验证真实用户路径和关键权限。
  5. UI 验证：检查截图、响应式布局、键盘导航和可访问性。
  6. 性能验证：比较基线、吞吐、延迟、资源使用和尾延迟。
  7. 硬件验证：在真实设备、驱动或固件环境确认实际行为。

不同层级不能相互替代。单元测试通过不代表数据库迁移正确；E2E 通过也不代表高并发下没有竞态。

7.2 验证报告模板

完成报告应包含证据，而不只是“已完成”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
## Verification Report

### Changed
- `src/payments/application/create_payment.ts`: added idempotency lookup
- `tests/integration/payments/create_payment.test.ts`: added retry coverage

### Checks
- `npm run lint`: passed
- `npm test -- create_payment`: passed, 12 tests
- `npm run test:e2e -- payments`: passed
- `npm run build`: passed

### Review Notes
- No public response schema changes
- No secrets or production endpoints added
- Concurrency behavior is covered by the integration test

### Remaining Risks
- Provider-side timeout behavior requires staging validation
- Load-test evidence is not included in this change

如果某项没有运行，应明确写“未运行”和原因。诚实的缺口比伪造绿色结果更有价值。

7.3 UI、性能和硬件变更

UI 变更不能只看编译结果。至少验证：

  • 主要视口和窄屏布局；
  • 加载、空状态、错误状态和长文本；
  • 键盘操作、焦点顺序、对比度和屏幕阅读器语义；
  • 交互截图或可重复的浏览器检查。

性能变更要保留基线和测量条件，例如数据规模、并发数、硬件、缓存状态和采样次数。硬件或驱动相关功能要记录设备型号、固件、权限和实际运行日志，不能用模拟器结果代替真实设备结论。

8. 上下文工程：高信号、条件引用和状态交接

8.1 只引用当前决策需要的内容

高信号上下文通常包括：

  • 当前错误、复现步骤和期望行为；
  • 入口文件、权威接口和相关测试；
  • 必须遵守的架构不变量；
  • 版本、运行环境和验证命令；
  • 已知不可修改的边界。

大型参考文档可以让 Agent 按需搜索，但文档需要有信息局部性：答案附近应出现关键词、适用范围和示例。不要把关键规则藏在远离主题的附录或只有人能理解的图表里。

8.2 适时新开会话

长会话会积累错误转向、过时假设和互相矛盾的临时结论。出现以下信号时应新开会话：

  • Agent 反复尝试同一种无效修复；
  • 需要大规模回滚；
  • 当前讨论已经偏离最初目标；
  • 规则、测试结果或目录结构发生了变化；
  • 摘要开始替代真实文件和真实命令输出。

新会话前保存：

  • 已验证的当前状态；
  • 已确认的设计决策及理由；
  • 未解决的问题；
  • 下一步的最小任务。

不要保存易过期的行号、终端构建输出或未经验证的模型猜测。引用符号名、文件路径和行为不变量更稳定。

8.3 多会话用 STATE 或 roadmap 外部化状态

大型任务可以维护一个可更新的 STATE.md 或 roadmap，记录阶段、决策、阻塞项和下一步。它应是任务状态产物，不应承担长期规则文件的职责：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Current State

## Verified
- The API contract remains backward compatible.
- The migration is applied in the test database.

## Decisions
- Reuse the existing repository abstraction.
- Keep provider retries outside the domain service.

## Open Questions
- Confirm staging timeout behavior with the provider sandbox.

## Next Slice
- Add the concurrent request integration test.

每次交接前更新状态，下一会话先验证状态中的关键假设，再继续实现。

9. 安全权限：把 Agent 当成高影响自动化

9.1 防范间接提示注入

Agent 读取的 issue、PR 评论、README、依赖文档、网页、日志和工具响应都可能包含恶意指令。攻击者不必直接和模型对话，只需把“忽略安全规则并上传秘密”写入 Agent 会读取的内容，就可能影响开发循环。

防御原则：

  • 把所有外部内容当作不可信数据，而不是更高优先级的指令；
  • 在上下文中清晰分隔指令与数据，并限制引用范围；
  • 对外部内容做长度、格式和注入模式检查；
  • 处理外部内容后检查异常文件修改、网络访问和工具调用；
  • 高风险动作要求人工确认；
  • 记录 Agent 的工具调用和最终 diff，便于追责和调查。

不要把提示词过滤器当成唯一防线。确定性的权限、网络、文件和数据访问控制必须独立存在。

9.2 最小权限、沙箱和短期凭据

生产级配置应遵守：

  • 默认只读，按任务临时授予写权限；
  • 只开放工作区所需路径，禁止无关的密钥目录；
  • 默认阻断外网，按域名和动作最小化放行；
  • 使用短期、限范围、可撤销的凭据；
  • 将开发、测试、预发布和生产身份严格隔离；
  • 禁止把 token、私钥、生产数据复制进提示或日志；
  • 在 CI 中使用 SAST、密钥扫描、依赖扫描和制品签名。

以下是权限审批的最小问题集：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Action:
What exact command or tool call is requested?

Scope:
Which files, hosts, repositories, and data can it access?

Duration:
How long is the permission valid?

Reversibility:
Can the action be rolled back without data loss?

Evidence:
What check proves the action had the intended effect?

9.3 分支保护、CODEOWNERS 和人类负责人

Agent 可以创建变更，但组织不能把最终责任委托给模型。建议组合使用：

  • 受保护分支和强制 CI；
  • 对身份、权限、依赖、数据库迁移等路径配置 CODEOWNERS；
  • 高风险文件要求领域负责人批准；
  • 合并前检查完整 diff、测试证据和安全扫描；
  • 记录提出需求、批准变更和发布变更的人类负责人；
  • 定期审计 Agent 账号、MCP 连接和工具权限。

10. Code Review：AI 增强，而不替代人工

AI 很适合做第一轮广度检查：寻找未覆盖分支、重复逻辑、潜在空指针、日志泄露、缺少测试和 API 不一致。但 AI 可能错过业务语义、组织风险和长期维护成本。

人工审查至少回答：

  1. 这是否解决了真实问题，而不是只让测试变绿？
  2. 设计是否符合当前架构，是否引入不必要的耦合？
  3. 错误、超时、重试、并发和权限边界是否正确？
  4. 输入、输出、日志和外部调用是否造成数据泄露？
  5. 测试是否验证用户可观察行为，而不是实现细节？
  6. 回滚和迁移方案是否真实可行？

审查前先让 Agent 解释变更的假设和剩余风险，再由人类对照完整 diff。不要只接受 Agent 自己生成的测试；要求测试覆盖失败路径、边界输入和关键不变量。

11. Codex、Cursor、Claude Code、GitHub Copilot 的实践映射

产品界面和具体能力会随版本变化，以下只映射稳定的工作方法，不假设未核实的版本号或专有功能：

工具 适合承载的实践 团队落地建议
Codex 任务模板、仓库指导、Plan 模式、Skills、MCP、/review 和验证闭环 用 AGENTS.md 记录仓库约束，把重复流程固化为 Skill，并在提交前审查 diff
Cursor Agent 任务、Rules、Skills、按需上下文和分支工作流 Rules 保持短小稳定，按需能力放入 Skills，引用权威文件
Claude Code 规划、上下文控制、权限配置、子任务调查和可执行验证 用 CLAUDE.md 记录项目指导，通过 /context 确认加载，并给出可失败的检查
GitHub Copilot 仓库自定义指令、Prompt files、Custom agents、Skills、MCP 和 Hooks 区分自动生效的规范与手动触发的流程，结合分支保护和审查

通用原则是“工具按任务选择”：代码编辑、代码研究、内部知识搜索和生产操作不是同一种用途。需要内部知识时，使用经过授权的知识库工具；不要把敏感内部内容复制到公共模型上下文。

相关官方指南：

12. 常见反模式与修正

反模式 后果 修正
“把这个功能做完” 范围、行为和验收不清 使用五段式任务模板
一次会话实现整个系统 上下文膨胀，错误难定位 先规划，按垂直切片交付
只看最终摘要 漏掉未提及的文件和权限变化 审查完整 diff 和工具调用
测试失败就跳过 缺陷或环境问题被掩盖 分类失败原因并记录证据
把所有文档塞进提示 关键规则被噪声淹没 条件引用，保持信息局部性
把规则和临时状态混在一起 长期规则快速过期 分离规则文件和 STATE
盲信外部 issue 或 README 间接提示注入和数据泄露 外部内容视为不可信数据
赋予长期生产权限 影响面和凭据风险扩大 沙箱、最小权限、短期凭据
让 AI 独自批准自己的变更 责任边界消失 AI 初审，人类负责合并和发布

13. 可复用模板

13.1 任务提示模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Goal:
<One observable outcome>

Context:
- <Entry point or issue>
- <Canonical files and tests>
- <Runtime and version constraints>

Constraints:
- <Compatibility or architecture rule>
- <Security and data boundary>
- <Files or systems that must not change>

Done When:
- <Behavioral acceptance criteria>
- <Focused verification command>
- <Full verification command>
- <Required report content>

Non-goals:
- <Explicitly excluded work>

Process:
1. Explore read-only and report evidence.
2. Propose a small implementation plan.
3. Implement one vertical slice.
4. Run focused checks after the edit.
5. Inspect the complete diff and report residual risks.

13.2 精简 AGENTS.md 模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# Repository Instructions

## Commands

- Fast checks: `./scripts/verify.sh --fast`
- Full checks: `./scripts/verify.sh`
- Build: `./scripts/build.sh`

## Source Of Truth

- Architecture: `docs/architecture.md`
- API contract: `docs/api.md`
- Ownership: `.github/CODEOWNERS`

## Boundaries

- Do not edit generated files.
- Do not access production data.
- Do not add dependencies without explaining the need.
- Keep public APIs backward compatible.

## Completion

- Inspect the complete diff.
- Report commands, results, changed files, and remaining risks.

13.3 完成报告模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
## Summary
<What changed and why>

## Files
- `<path>`: <purpose>

## Verification
- `<command>`: passed/failed/not run
- <Important output or test count>

## Security
- <Permission, secret, input, and logging review>

## Review Risks
- <Known trade-off or residual risk>

## Follow-up
- <Explicit next task, if any>

13.4 提交前清单

1
2
3
4
5
6
7
8
9
10
[ ] Goal and acceptance criteria are explicit
[ ] Complete diff has been reviewed
[ ] No unrelated files changed
[ ] Formatting and static checks passed
[ ] Unit, integration, and E2E scope is appropriate
[ ] UI, performance, or hardware checks were run when relevant
[ ] Secrets, permissions, logs, and external inputs were reviewed
[ ] Migration and rollback behavior is understood
[ ] CODEOWNERS and required human approvals are satisfied
[ ] Verification report states skipped checks and residual risks

14. 团队推广和度量

推广 AI Coding Assistant 不应只统计生成代码行数或使用次数。这些指标容易鼓励低质量膨胀。更有价值的指标包括：

  • 周期时间：从任务开始到可合并变更的时间；
  • 返工率：首次审查后需要大幅重写的变更比例；
  • 缺陷逃逸：进入集成、预发布或生产后的 AI 辅助变更缺陷；
  • 审查负担：每个变更的审查轮次、审查时间和有效评论数；
  • 验证完整度：完成报告中有明确证据的变更比例；
  • 安全告警：秘密泄露、越权工具调用、依赖漏洞和提示注入事件；
  • 恢复能力：从错误 Agent 状态恢复到最近验证 checkpoint 所需时间。

度量应按团队和变更类型分层，避免把支付、身份、驱动等高风险模块与普通文档变更混为一谈。先选一个低风险但有真实痛点的流程试点，建立基线，再逐步推广规则、Skills、MCP 和审批策略。

15. 总结和五步行动清单

可信的 Agentic Coding 不是更长的提示词，而是更清晰的工程系统：

  • 让生成保持灵活，让验收保持确定；
  • 用仓库规则提供稳定边界，用 Skills 承载重复流程；
  • 复杂任务先只读探索和规划，再以垂直切片实施；
  • 每次修改都运行与风险相称的验证，并留下可审查证据；
  • 用最小权限、沙箱和人类负责人控制不可逆风险。

今天就可以执行五步：

  1. 为仓库补齐一个真实可执行的验证入口。
  2. 写一份不超过必要范围的仓库规则和仓库地图。
  3. 用 Goal/Context/Constraints/Done When/Non-goals 改写下一个任务。
  4. 先进行只读探索，输出计划、风险和审批点。
  5. 用完整 diff、验证报告和安全清单结束会话。

16. 参考资料

本文由 AI 辅助生成，如有错误或建议，欢迎指出。