Coding Plan 上手：环境与工作流

Coding Plan 是 GLM 面向编码场景的套餐服务，围绕 GLM-5.3/5 系列的推理与编码能力，把模型接入你已有的开发环境。这篇不讲概念，只讲怎么把它跑起来：环境怎么配、第一条提示词怎么写、日常迭代用什么节奏。具体套餐内容与额度以官方页面为准。

一、环境准备：三件事

接入 Coding Plan 通常涉及三步：拿到凭证、选择接入方式、验证连通。

1. 凭证：在官方控制台开通 Coding Plan 后获取 API Key（具体入口以官方页面为准）。Key 不要写进代码仓库，放环境变量。 2. 接入方式：常见有两条路——走 BigModel API 平台直接调接口；或在支持自定义模型端点的编码工具（如各类 CLI Agent、IDE 插件）里填入 GLM 的 base URL 与模型名。 3. 验证：先用一个最小请求确认链路通，再谈工作流。

环境变量示例（Linux/macOS）：

bash
export GLM_API_KEY="你的Key"
export GLM_BASE_URL="https://open.bigmodel.cn/api/paas/v4"  # 以官方文档为准

二、第一条提示词：把任务说成规格

很多人第一次用编码模型，写的是「帮我写个爬虫」。这种开放任务产出质量不稳定。更有效的做法是把任务写成规格：输入、输出、约束、验收标准。GLM-5 系列开启 thinking 深度思考后，对结构化规格的推理明显更稳。

可直接复制的模板：

你是一名资深后端工程师。请实现一个函数，要求如下：

【语言与版本】Python 3.11，仅用标准库
【输入】字符串列表 paths，每项形如 "dir/sub/file.txt"
【输出】按目录层级聚合的字典：{目录: [文件名,...]}，文件按字典序排序
【约束】不修改入参；处理空列表；路径中不允许出现 ".."，出现则抛 ValueError
【验收】先给出至少 5 个测试用例（含边界），再给出实现
【输出格式】测试代码和实现代码分成两个代码块，各加一行说明

要点：约束放在任务前面，验收标准逼模型先想清楚再写码。

三、日常工作流：小步提交 + 追问式迭代

编码场景最忌一次性丢大任务。推荐节奏：

• 拆小：一次只让模型改一个函数或一个模块，改完立刻跑测试。
• 带着报错追问：测试挂了不要重新描述任务，直接把报错栈和相关代码贴回去，让模型基于上下文修复。
• 明确「不要动什么」：告诉模型哪些文件不许改，能显著减少越界修改。

追问模板：

上一轮你修改了 src/parser.py，测试 test_parser.py 有 2 个用例失败。

报错信息：
<粘贴完整 traceback>

相关代码：
<粘贴失败断言附近的代码>

要求：
1. 只修改 src/parser.py，不动测试文件和其他模块
2. 先解释失败根因（一两句话），再给出修复后的完整函数
3. 如果你认为测试本身有误，请说明理由并给出建议的测试修改，但默认不改动测试

四、什么时候开 thinking 模式

GLM 的深度思考模式适合三类任务：架构决策与方案对比、复杂 bug 的根因分析、跨多文件的改动规划。简单的代码补全、格式调整、单函数实现，关掉 thinking 更快也更省额度。判断标准：这个任务如果让一个中级工程师做，需不需要先想十分钟？需要，就开 thinking。

需要读图的场景（UI 截图还原、报错截图解析）可以配合 GLM-4V 的视觉理解能力，把截图和文字描述一起给模型。

五、额度与工具选择

Coding Plan 的额度规则、支持的并发与模型档位以官方页面为准。选接入工具时关注三点：能否自定义 base URL（决定能否接 GLM）、能否开关 thinking（决定成本可控）、能否方便地贴长上下文（决定追问式迭代的效率）。

Coding Plan 的价值不在模型本身，而在把 GLM-5 系列的编码能力嵌进你每天的工作流。先把环境跑通，再用「规格化提示词 + 小步迭代」的节奏用起来，两三个迭代周期后你会自然形成自己的模板库——到时候欢迎回 GLMMODEL 看看别人的写法。