用 GPT-5.6 写了两个月代码之后，我发现一个规律：代码越靠近核心逻辑，它的可控性越差。
最近在kulaai（titiai.cn）上对比了几个模型的代码能力，GPT-5.6 在工具函数层面表现很好，但到了核心业务逻辑就开始出现不可预测的行为。这个发现改变了我使用它的方式。
工具函数：基本可以放心用
工具函数是那种功能单一、输入输出明确、没有副作用的代码。日期格式化、字符串处理、数据转换这类。
我让 GPT-5.6 生成了大概 30 个工具函数，只有 1 个有问题——一个金额格式化函数在处理负数时少了个负号。其他 29 个全部能直接用，连测试都跑过了没问题。
这个层面它的可控性很高，输出可预测，边界条件处理得当。
业务逻辑：需要验证但可以依赖
业务逻辑比工具函数复杂，涉及多步判断、条件分支、数据流转。比如订单状态机、权限校验链、支付流程这类。
我让它生成了一个订单状态机，12 个状态、28 个转换规则。输出的代码结构清晰，注释完整。但跑测试发现两个问题：一个边界条件漏掉了（订单取消后不能再退款），一个并发场景下状态可能不一致。
这个层面它的可控性中等，80% 的输出可以直接用，但 20% 需要修正。关键是你不知道哪 20% 有问题，所以必须验证。
核心逻辑：一定要自己把关
核心逻辑是系统的命脉——认证授权、资金流转、数据一致性。这些地方出错不是改代码的事，是线上事故。
我让它重构了一段支付处理代码，输出看起来很专业。但仔细看发现退款和支付放在同一个事务里，实际业务中会导致锁定时间过长。还有一次它把同步逻辑改成了异步，引入了竞态条件。
这个层面它的可控性低，输出可能看起来没问题但实际有隐患。必须人工审查，不能直接用。
我现在的使用策略
工具函数直接用，跑个 lint 就够了。业务逻辑生成后跑测试验证，重点关注边界条件。核心逻辑只让它给建议，最终实现自己写。
这个策略下来，效率比之前高了不少，同时风险控制在可接受范围内。
GPT-5.6 的代码可控性不是均匀的，越靠近核心越需要人工把关。找到这个边界，才能既用好它又不被它坑。
