工具越强，对“如何交代任务”的要求反而越高——因为一旦理解错误，能造成的破坏也随之变大。
两周前遇到一个典型案例：同一个电力营销系统，同一个修改电费计算的需求，交由两名开发人员使用AI处理。一人半小时搞定，仅核对Diff后直接合并；另一人折腾大半天，AI修改后设计文档未同步、接口规范对不上、测试缺失，甚至牵连修改了十几个不相关文件，回滚困难。
使用的是同一个模型，差别何在？对比对话记录发现，根本不在AI能力，而在于任务交代是否清晰。前者提供了包含文件名、行号、规范出处的具体指令；后者仅表示“帮我看看电费计算这块有没有问题”。
AI Coding发展至今，Agent已能自主搜索代码库、读取多文件、调用工具并连续执行。但工具越强，对任务指令的要求越高。以下是在实践中总结的AI任务交付经验。
一、问题剖析：模糊指令的隐患
以“帮我检查一下电费计算这里有没有问题”为例，这类指令存在诸多漏洞：未指明具体文件与方法、未明确是阶梯电价还是峰谷电价、缺乏判断依据（代码规范或业务规则）、未要求同步文档与测试。
指令模糊时，AI只能靠猜，而“猜出来的结果往往包装得十分逼真”。在企业级系统中，代码只是网络上的一个节点，牵一发而动全身。孤立地修改代码而不顾及业务规则、系统架构与接口，必然导致系统整体不一致。问题的核心不在于AI是否会写代码，而在于开发者是否具备将工程任务讲清楚的能力。
二、核心框架：AI任务交代的四步法
经过实践验证，高效的AI任务交付可归结为四个阶段：说清楚、问明白、控过程、验结果。
1. 说清楚：给事实锚点，划定清晰边界
最有效的沟通方式是提供事实锚点，而非使用形容词。将“这里好像有点问题”替换为具体的文件路径、行号及对照规范。例如：
power-metering/.../settlement/ElectricityCalcService.java:46-48
调用电费计算服务时，没有拼装《电费计算接口规范 v1.2》要求的输入字段，请检查这个调用链，说明问题原因。
同时，必须明确划定任务边界，说明“做什么”与“不做什么”。范围、对象、任务与边界四层信息一次说清，可有效防止AI自由发挥。
2. 问明白：要求提供依据，鼓励主动提问
面对复杂问题，需将提问方式从“你觉得为什么”转变为“你的判断依据是什么”，并明确要求AI在缺乏明确依据时直接说明，避免基于错误假设生成代码。
此外，对于AI无法从现有文档中推断的历史遗留问题或特殊业务规则，应明确要求其“先向我提问，确认后再继续”，使AI从单纯的“回答机器”转变为真正参与项目的协作者。
3. 控过程：评估影响范围，设置人工确认闸门
在企业研发中，修改一处代码往往牵动十几处关联。因此，复杂任务必须先评估影响范围（如架构文档、接口定义、数据模型等），再决定改动范围。
切忌盲目点击“Apply”直接应用修改。稳妥的流程应遵循“先分析、出方案、人确认、再执行”的原则。对于删除文件、修改公共接口、操作数据库等高风险操作，必须设置前置的人工确认闸门。
4. 验结果：多层级验收，拒绝“自嗨式”完成
不能轻信AI的“已完成”提示。靠谱的验收应包含三层：一是让AI自查遗漏；二是通过编译、单测等工具进行验证；三是最关键的，人工核对Git Diff，确认未篡改授权范围之外的文件，拿事实去核对最终结果。
三、实战演练：完整任务拆解与基建沉淀
1. 完整案例：标准八步改造法
以“电费计算接口新增峰谷电价规则”为例，完整的AI Coding任务应包含以下步骤：
- 给上下文：阅读相关规范文档、源代码及测试用例。
- 明边界：明确本次仅处理峰谷电价计算，不修改其他规则。
- 给范例：提供参考的实现代码结构。
- 析依据：要求AI说明当前实现不支持新规则的原因及依据。
- 留口子：对不确定的业务规则，要求AI先提问。
- 摸影响：分析变更对文档、接口、数据及测试的影响面。
- 出方案：输出完整修改计划，暂不修改代码。
- 严收口：人工确认后执行，并通过测试与核查确保无遗漏。
2. 基建沉淀：将规则固化为项目基础设施
如果每次都要向AI重复“表名必须下划线”等基础规则，说明这些规范亟需沉淀。利用Cursor、Claude Code等工具的机制（如.cursor/rules/、AGENTS.md等），将架构规则、命名规范、安全边界直接写入代码仓库。让Prompt从一次性对话内容，升级为项目研发基础设施的一部分，使AI优先读取规则再执行任务。
3. 实用模板：5个高复用Prompt模板
掌握以下五个核心模板，即可应对绝大多数开发场景：
- 排查类：排查[范围]下的[对象]，找出[问题]，给出位置、依据及建议。先分析，不修改。
- 理解类：阅读[相关文件]，分析[问题]原因。对无法确定的信息不猜测，向我提问。
- 生成类：基于[源文件]和[规范]，生成[目标产物]，格式参考[模板]。不确定处先提问。
- 变更类：根据确认的方案修改[范围]，修改前检查关联设计、代码和测试，严禁越权修改。
- 收口类：核查本次变更涉及的所有文档、代码和测试，检查遗漏与违规，通过检索和Diff验证并列出结果。
四、总结
模型能力越强，能接手的任务越复杂，理解偏差带来的代价也越大。未来真正稀缺的能力，并非编写花哨的Prompt，而是清晰地界定AI的工作边界——定义问题、提供上下文、约束行为、判断方案、控制执行时机并设定验收标准。
在电力等复杂行业中，业务规则与系统架构才是真正的硬骨头。AI能辅助搜索与编码，但“什么能改、什么是对的”，仍需人类拍板。本文总结的四步法，本身也应被封装为标准Skill（如开源项目 coding-task-refiner，可通过GitHub获取），以实现经验的规模化复用。
核心心法：小任务靠说清楚，复杂任务靠控过程，关键任务一定要验结果。