开发者 AI 工作流检查清单

可靠的 AI 工作流不是某一句提示词，而是一个可重复循环：定义任务、提供安全上下文、要求可检查输出、验证结果，并记录证据。

1. 定义任务

打开 AI 工具前，先用一句话写清任务。

适合的任务形态：

• 解释这个错误，并列出可能原因。
• 为这个行为起草测试。
• 对比两个实现方案。
• 在不改变公开契约的前提下重构这个函数。
• 把这些笔记整理成需求。

除非 Agent 有明确文件、约束和检查方式，否则避免 Build the whole feature 这类让 AI 接管整个任务的提示词。

2. 准备安全上下文

只提供完成任务所需的上下文：

• 相关代码、日志、文档或需求。
• 期望行为和实际行为。
• 不能改变的约束。
• 已有命令、测试或示例。

移除密钥、客户隐私、内部策略，以及不应离开环境的源码。

3. 要求可检查输出

让答案容易审查：

Return:
1. Short diagnosis.
2. Recommended change.
3. Risks and assumptions.
4. Verification steps.

结构化任务可以要求 JSON、Markdown 表格、SQL、测试用例或补丁级说明。格式越具体，越容易检查。

4. 信任前先验证

选择匹配任务的证据：

• 代码：运行测试、类型检查、lint 和人工审查。
• API 或库细节：查看官方文档。
• 安全相关工作：依据可信资料和团队策略。
• 内容：检查来源、语气、事实和授权。
• 数据转换：对照样例输入和输出。

无法验证的答案，只能当作想法，不能当作结果。

5. 记录发生了什么

重要工作可以留下简短记录：

AI assisted with: [task]
Verified by: [docs, tests, command, review]
Remaining risk: [known limitation]

这能帮助后续审查者看清哪里使用了 AI，哪里应用了人工判断。

常见失败模式

• 提示词隐藏了最重要的约束。
• 助手说只是重构，却改变了行为。
• 答案给出精确事实，但没有来源。
• 任务包含本应脱敏的数据。
• 验证步骤模糊、缺失或无法执行。

最终结论

把 AI 当作工程工作流里的快速协作者。上下文、隐私、审查和证据仍由你负责。