PAYATHON 2026

如何编写提示词，让 AI coding agents 更全面地分析和改造现有系统？

架构老王

要改善这类任务的结果，需要把设计意图写成可检查的行为要求，让 agent 先分析现有代码，再提出方案并实施修改。只要求“把 X 从请求移到 endpoint”，并没有明确要求 agent 查找 X 的实际使用位置，或实现按需获取。

提示词可以减少理解偏差，但不能保证 agent 自动补齐业务知识，也不能保证它做出可靠的架构判断。关键决策仍需要你审核；在方案阶段审核，通常比代码生成后逐项纠正更容易控制范围。

先明确这次改造真正要改变的行为

原始提示词描述的是接口变化：从 CalculateFeesRequest 中移除 X，让应用 B 通过 endpoint 获取等价数据。应用 B 收到请求后立即获取 X，也符合这个描述。

如果希望按需获取，就要补充具体条件：

  • 执行路径不使用 X 时，不调用新增的 endpoint。
  • 执行路径使用 X 时，在首次需要它的位置附近获取。
  • 明确同一次计算中是否允许重复获取；如果希望复用，说明复用范围。
  • 保持计算结果及必要的数据一致性语义，并说明允许变化的行为。

“先做一些重构”“提高代码质量”也需要限定范围。例如，只整理与 X 的传递和消费有关的代码，遵循项目现有风格，不顺便改造无关模块。

要求先给出代码依据和方案

第一阶段可以要求 agent 暂不修改代码，先回答以下问题：

  1. X 在哪里生成、传递和读取？列出相关文件、方法和调用路径。
  2. 哪些计算分支必须使用 X，哪些不需要？判断依据是什么？
  3. 哪些现有代码结构阻碍按需获取？是否需要先做局部重构？
  4. 改为远程获取后，数据时点、失败处理和调用次数会发生什么变化？
  5. 准备用哪些测试证明行为符合要求？

要求 agent 区分代码中能确认的事实、推断和待确认事项。如果它只能访问应用 A，就不能把应用 B 的消费位置当作已核实的事实，应将这项分析交给能够访问 B 的实例。

可直接改写使用的提示词

提交前，应根据实际业务调整数据一致性和调用次数要求。

背景：
应用 A 当前通过 CalculateFeesRequest 向应用 B 传递数据集 X。
需要改为由 A 提供 endpoint，由 B 获取等价数据。

目标：
移除 CalculateFeesRequest 中的 X，并让 B 按实际计算需要获取 X。
不需要 X 的执行路径不得调用该 endpoint。
需要 X 时，在首次实际使用的位置附近获取。
请分析同一次计算中是否需要复用获取结果，并说明理由。

第一阶段：分析，暂不修改代码。
1. 查找 X 的构造、传递和消费位置，列出文件、方法及调用关系。
2. 区分需要 X 和不需要 X 的执行路径，给出代码依据。
3. 指出数据时点、错误处理、超时和接口兼容性方面的待确认事项。
4. 提出实现方案和必要的局部重构，说明每项重构如何支持目标。
5. 给出测试计划，并列出你无法从代码确认的业务假设。
只能访问单个应用时，明确说明分析范围，不推断另一个应用的实现。
完成后等待我确认方案。

第二阶段：按确认的方案实施。
遵循仓库现有的接口、错误处理和测试约定。
先完成必要的局部整理，再修改数据获取方式。
不要扩展到与本次任务无关的重构。

验收条件：
- 不再通过 CalculateFeesRequest 传递 X。
- 不需要 X 的路径不获取 X。
- 需要 X 的路径获得符合约定的数据并保持预期计算行为。
- 调用次数、失败行为和数据时点符合确认后的方案。
- 运行相关测试，并如实报告结果；无法运行时说明原因。

交付：
总结修改位置、行为变化、测试结果和仍未解决的问题。
另行生成给应用 B 的 agent 使用的交接提示词，包含已确定的接口契约、
行为要求、验收条件以及尚待确认的事项。

用测试表达“按需”的含义

这次改造的测试应直接检查是否发生数据获取，不能只检查最终计算结果。

场景应检查的行为
不使用 X 的计算路径endpoint 调用次数为 0
使用 X 的计算路径获取 X，并验证计算结果
同次计算多处使用 X按已确认的复用策略检查调用次数
获取 X 失败按约定返回错误或执行明确允许的降级

代码结构可以类似下面这样。方法和类型名称仅用于说明，实际判断条件必须来自现有业务逻辑。

if (RequiresX(context))
{
    var x = await dataClient.GetXAsync(
        context.DataKey,
        cancellationToken);

    ApplyX(context, x);
}

审核时需要确认，RequiresX 能否在不获取 X 的情况下正确判断，GetXAsync 是否仍在其他入口被提前调用。仅把获取逻辑包装进一个方法，不能证明已经实现按需获取。

把数据语义写进交接要求

从请求携带 X 改成稍后远程获取，可能改变计算使用的数据。原来随请求发送的数据可能代表某个时间点的状态；如果新 endpoint 返回查询时的最新状态，两者未必等价。

因此需要明确：B 应获取请求发起时的快照、某个版本的数据，还是查询时的最新数据。具体选择取决于业务，不能仅凭原始问题确定。

给应用 B 的交接提示词应包含 A 已实现的实际接口契约，包括请求字段、响应结构、错误语义和数据时点。尚未确定的内容应列为待确认项，避免两个 agent 各自作出不同假设。

将重构限定为支持本次目标的改动

可以要求 agent 说明每项重构要解决的结构性障碍、准备如何调整，以及如何验证行为没有意外变化。例如，将 X 的消费逻辑集中到可识别的位置，可能有助于控制获取时机；大范围重命名或重新分层则未必有必要。

为了让 agent 从整体考虑改动，可以要求它先展示调用关系和业务假设，再解释设计选择，最后用测试证明关键行为。你也能在生成大量代码前发现理解偏差，更容易判断哪些决策仍需要自己参与。

备注：内容仅供参考。