代码生成与审查的工程边界
让维护成本参与决策
顾时安处理研发工具里的“代码生成与审查的工程边界”时，通常不会先讨论工具多不多，而是先把任务压到一个具体场景：谁在什么条件下发起操作，系统需要留下什么结果，哪一步出错必须停止。只要这个场景还说不清，后面的架构图和参数表就很容易变成装饰。短期能跑的方案未必适合长期维护。除了实现时间，也要比较排障入口、依赖数量、配置复杂度和新成员能否理解。选择并非追求最炫的技术，而是选择团队能持续维护、出问题能找到人的那一条。
最后用真实使用场景收尾：准备一次正常输入、一次边界输入和一次失败输入，检查结果、提示和记录是否一致。若这三类路径说不清，说明设计还没有真正收住。
代码生成能缩短样板实现时间，代码审查则要检查它是否符合现有系统。两者都不能只看语法是否通过。
生成前提供约束
明确语言版本、已有接口、错误处理方式和禁止修改的范围。上下文越准确，后续返工越少；但不要把无关仓库内容和敏感配置混入提示。
审查回到风险点
重点看权限、输入校验、并发、资源释放、兼容性和测试缺口。生成的解释可以作为线索，最终结论仍应由差异、测试和运行记录支撑。
生成和审查要走两条线
代码生成可以缩短起草时间，却不该把审查降格为看一眼语法。审查者首先要确认改动是否回答了原问题，再看边界条件、兼容性和测试是否覆盖。模型生成的注释、测试名和错误处理很容易显得完整，但真正执行后才知道是否与项目约定一致。
实践中可以限制一次生成的范围，例如只处理一个函数或一个明确的接口变更。范围小，差异就容易读，失败也容易回退。若内容涉及认证、支付、删除数据或权限判断，必须由熟悉业务的人复核，不能因为静态检查通过就直接合并。
审查工具也有盲区。它能指出重复逻辑或空指针风险，却未必知道一次字段重命名会影响报表。把它当成第二双眼睛很有用，把它当成签字人就不合适。最终留下的应是可解释的改动和可运行的验证结果。
对生成代码的评价不应只看能否编译。还要问它是否遵循已有的错误处理方式，是否把原本清晰的逻辑绕复杂，是否新增了不必要的依赖。审查意见最好落到具体差异，而不是笼统地说有风险。这样作者能修改，下一次生成时也能把项目约束给得更准确。审查是把关，也是把隐性的工程习惯变成可传递的规则。
遇到无法判断的改动，最好的做法是缩小差异再看。把重构和功能修改拆开，把生成内容先放到草稿提交，审查者就能逐项验证。工具可以提高产出速度，但不能压缩理解代码所需的时间；该慢下来的地方仍要慢下来。
把审查结果回写到规则也很重要。若某类问题频繁出现，就补上测试、静态规则或提交模板；若只是特定场景的取舍，就保留为案例说明。这样下一次生成和审查都能站在已有经验上，而不是重新开始。
