Coding Plan 场景：仓库级编码提示词怎么写

很多人用 GLM Coding Plan 做仓库级任务时，把提示词写成一句话需求，然后抱怨模型改不准。问题多半不在模型，而在上下文组织：仓库级任务涉及多文件、多模块依赖，模型需要的不只是目标，还有约束、边界和验收标准。这篇文章给出一套适合 GLM-5 系列的仓库级提示词结构，thinking 模式下配合使用效果更稳。

一、仓库级提示词的五段结构

单文件任务提示词可以随意，但仓库级任务建议固定结构，五段缺一不可：

1. 角色与任务目标：一句话说清要做什么，动词开头，避免「帮我看看」「优化一下」这类模糊表述。 2. 仓库上下文：技术栈、目录结构关键部分、相关模块的职责。GLM-5 系列 context 窗口较大，但塞进整个仓库不如给出精准切片。 3. 约束条件：编码规范、不能动的文件、依赖版本限制、兼容性要求。 4. 执行步骤：让模型先输出计划再改代码，thinking 模式下这一步尤其有效——深度思考会沿着你给的步骤展开推理，而不是自由发挥。 5. 验收标准：怎么算完成，需要跑哪些测试，输出什么格式。

二、任务拆解模板（新功能开发）

text
【角色】你是本项目的高级工程师，熟悉本仓库全部模块。

【任务】在用户服务模块中新增「手机号绑定」功能：
- POST /api/user/phone/bind 接口，接收验证码并完成绑定
- 验证码 5 分钟有效，同一手机号 60 秒内只能发一次

【仓库上下文】
- 技术栈：Spring Boot 3 + MyBatis-Plus + Redis + MySQL 8
- 相关文件：
  - src/user/controller/UserController.java（现有接口风格参考）
  - src/user/service/UserService.java（业务逻辑层）
  - src/common/exception/BizException.java（统一异常）
- 短信发送已有工具类 src/common/sms/SmsClient.java，直接复用

【约束】
- 不要修改除上述文件以外的新增文件之外的任何现有逻辑
- 遵循仓库现有代码风格：构造器注入、统一 Result 包装
- SQL 变更单独输出 migration 文件

【执行步骤】
1. 先输出实现计划（涉及文件、接口签名、表结构变更）
2. 我确认计划后，再输出完整代码

【验收】
- 列出需要补充的单元测试用例
- 说明边界情况：验证码过期、重复绑定、并发发送

第三步的「先计划后代码」是关键。直接让模型输出代码，仓库级任务容易漏改关联文件；拆成两轮，第一轮的计划你可以人工校对，纠错成本远低于事后回滚。

三、Bug 修复模板（带复现信息）

text
【任务】修复订单列表接口偶发 500 错误。

【现象】
- 复现率约 5%，集中在订单量大的商户账号
- 报错日志（关键片段）：
  NullPointerException at OrderListService.java:87
- 请求参数示例：{ "merchantId": 88231, "page": 1, "size": 50 }

【已排查】
- 数据库中该商户存在 3 笔 refund_status 为 NULL 的历史订单
- 怀疑是状态过滤逻辑未做空值处理，未最终确认

【要求】
1. 先给出根因分析（引用具体代码行），不确定的地方明确标注「待确认」
2. 给出最小改动修复方案，不要顺手重构
3. 补充一个防回归的单元测试

【输出格式】根因分析 → 修复 diff → 测试代码，三段分开输出

写 Bug 修复提示词时，最容易犯的错是把「已排查信息」省掉。把你确认过和怀疑的点都写进去，模型会沿已有线索收敛，而不是把整条调用链重新推一遍——token 花在刀刃上，正确率也更高。

四、多轮迭代怎么维持上下文

仓库级任务很少一轮完成。迭代时的两条经验：

• 每轮只追加增量信息：不要每轮重发整个模板，只发「上一步第 3 个文件里，把参数校验改成……」这种相对引用。GLM Coding Plan 会话内上下文是连续的，重复粘贴大段代码反而稀释重点。
• 阶段切会话：功能开发完成进入 code review 阶段时，开新会话并只粘贴 diff。长会话后期模型容易被早期错误尝试带偏，新会话相当于一次干净的上下文重建。

五、和 API 直接调用的区别

如果你同时用 BigModel API 做自动化流水线（比如 CI 里自动生成 commit message），提示词结构可以复用上面五段式，但要注意 API 调用没有会话记忆，每个请求都要自带完整上下文；是否开启 thinking 参数也会影响输出结构和延迟，具体参数以官方文档为准。本地部署开源权重的场景同理，上下文组织方式不变，主要差异在窗口长度和推理配置。

仓库级编码的核心不是把提示词写长，而是把约束和验收写清楚。上面两个模板直接改字段就能用，跑过三五个真实任务后，你会自然形成适合自己仓库的固定版本。