CodeGeeX 是智谱推出的 AI 编程助手，以插件形式装进编辑器，做补全、问答、代码解释和跨语言改写。它适合的场景很具体：手上有一个能跑的项目，需要有人在旁边接下半句、解释一段陌生逻辑、把一段代码换成另一种语言。不适合的场景同样具体：需求还没想清楚，指望它替你做架构决策。
先把补全调成不打断思路的节奏
补全容易出的问题不是写得差，是太积极。一行还没想完，灰色的建议已经铺了三行，手一抖按下 Tab，代码结构就歪了。先把触发方式调成手动，或者在写注释和函数签名时临时打开，思路走顺了再让它接。
引导补全靠两样东西：函数名和注释。写一个语义明确的函数名，再跟一行说明「读取 PDF，返回金额与日期，缺字段返回 None」，它补出来的东西基本能用。只写 process 这类泛称，它只能猜，猜出来的往往是通用模板。
补全的验收标准是「读得懂」。变量名是否达意、异常有没有处理、边界条件有没有考虑。连续按 Tab 拼出来的代码，跑得通也可能没人敢改。
代码问答要给足上下文
「这段代码为什么报错」是效率很低的问法。有效的问法是三件套：完整报错信息（含堆栈）、相关代码（不只是出错那一行）、运行环境（语言版本、框架、依赖）。缺哪一样，它就只能给通用猜测。
选中范围也有讲究。选中一个函数，它讲的是这个函数；选中整个文件，它可能抓不住重点。做法是先选可复现的最小片段，问不通再往外扩一层。
解释代码时要求它「按执行顺序讲」，而不是「这段代码做了什么」。前者会带出调用链和状态变化，后者只给一句概括。接手陌生模块时，让它输出「输入、关键分支、输出、副作用」四项，比读一遍注释快。碰到需要推理的复杂逻辑，什么时候该让它多花时间想，可参考深度思考什么时候开里的判断。
跨语言改写的四个雷区
| 语言差异 | 具体表现 | 改写时怎么写要求 | 验收看什么 |
|---|---|---|---|
| 异常处理 | 有的语言随手抛，有的要声明与包装 | 要求映射到目标语言的异常体系，不要吞掉 | 每个捕获分支有没有实际处理 |
| 并发模型 | 协程、线程、事件循环不是一回事 | 说明目标运行环境，要求不共享可变状态 | 有没有引入竞态 |
| 数值精度 | 浮点误差、整型溢出、定点小数 | 涉及金额要求用定点或高精度类型 | 边界值用例是否通过 |
| 空值与类型 | 可选类型、隐式转换宽严不一 | 要求显式判空，关掉隐式转换 | 空输入、类型不符的用例 |
这张表可以直接当提示词用。改写前把源语言、目标语言、运行环境写清楚，再补一句「指出这段逻辑在目标语言里容易出错的地方」，它会主动标出风险点。要求写得更具体的办法，见提示词库的改编动作。
用测试当验收，不用眼睛当验收
改写和补全的产物，靠读是读不出问题的。可行流程是：先让它为原代码生成一组测试（正常值、边界值、异常输入），跑通，留下作为基线；再改写；改完用同一组测试跑一遍。测试通过不等于正确，但至少把「明显改坏」挡在外面。
没有测试的老项目，退一步的做法是准备几组真实输入，记录原函数的输出，改完后逐组比对。这一步花的时间，通常比事后排查一次线上问题少。
还有个细节：让它生成测试时，明确要求覆盖异常路径。默认生成的用例大多只走正常分支，断言也偏弱，看着一片绿，其实什么都没验证。
四类任务的可用度
| 任务 | 怎么给输入 | 验收标准 | 常见失败 |
|---|---|---|---|
| 行内补全 | 函数签名加一行注释 | 命名达意、异常有处理 | 补出用不到的参数与分支 |
| 解释代码 | 选中单个函数，说明关注点 | 能说清输入输出与副作用 | 把注释复述一遍当解释 |
| 跨语言改写 | 源与目标语言、运行环境、测试 | 同一组用例结果一致 | 并发与精度悄悄变了 |
| 生成单测 | 给出被测函数与其依赖 | 覆盖边界与异常路径 | 只测正常路径，断言过弱 |
补全与解释这类任务，装上就能用，效果当天可见；改写与测试要投入时间准备输入和基线，回报在项目周期后半段才显出来。按这个顺序引入，团队接受度会高一些。
它读不到的东西
插件看到的是你给它的那段代码，不是整个系统的运行状态。跨文件的重构、依赖注入的装配关系、配置在部署时怎么被覆盖，这些它只能猜。涉及多模块改动，先把调用链画出来，再让它改单点。
私有框架和内部封装的用法，它大概率不知道，会用公开库的写法硬套。这类代码让它解释可以，让它生成要谨慎，生成完必须对照内部文档核一遍。
安全与性能更不能交给它判断。生成的代码可能有注入风险，也可能在大数据量下退化，这些要跑静态检查和压测才能发现。它的输出是初稿，不是结论。
还有授权问题。它可能补出一段与某个开源项目高度相似的代码，直接进商业项目会有风险。关键模块建议做一次相似度筛查，来源不明的整段代码不要直接落地。
CodeGeeX 用法速查
- 补全先改手动触发，写完注释和签名再让它接
- 问答三件套：完整报错、相关代码、运行环境
- 跨语言改写先定四件事：异常、并发、精度、空值
- 验收靠同一组测试跑两遍，不靠肉眼读
- 跨文件重构与私有框架，先画调用链再改单点
三个日常问题
- 补全总在不想的时候弹出来，怎么处理？：改成手动触发，或者只在写注释、写签名时开。多数编辑器插件都提供开关，具体位置以当前版本为准。
- 它写的代码风格和项目不一致，怎么让它靠拢？：贴一段项目里的既有代码当样例，说明命名、日志、错误处理的习惯，再让它照着写。比说「遵循项目规范」具体得多。
- 老项目没有测试，改写后怎么确认没改坏？：先跑一遍真实输入，把原输出存档，再改写，逐条对比。差异逐条解释，解释不清的就回退。有效的提示词与命令，按项目存一份，团队里能省下重复试错，这类归档可参考历史记录的搜索与导出。
