用AI写代码可以是好事，但要做出可靠软件，仍需理解问题、识别边界并评估结果。AI并没有消除这些工作，反而往往放大了良好工程习惯的作用。
“前提是你已经是一名优秀开发者”并不是排斥新手。初学者同样可以借助AI学习、试验和探索代码。关键区别在于是否理解生成的代码解决了什么问题、引入了什么风险。AI给出结果后，判断它是否正确的人仍然是你。
适合使用AI的场景
AI尤其适合边界清晰、可回退、结果可观察的任务，例如起草数据转换、建议测试用例、简化文档、解释陌生API，或为重复重构提供方案。
任务必须明确。“让这个模块现代化”很模糊；“在不改变接口响应格式的前提下，将这三处重复检查提取为独立方法，保留现有测试并补充边界测试”，才是有清晰边界的任务。
经验让我先问清问题，再写代码
优秀开发者不只是掌握一种语言或框架，还要把产品需求转化为技术要求、理解现有架构、识别变更影响范围，并衡量备选方案的代价。当模型提出方案时，以下问题仍需工程判断：
- 这次变更满足了真实用户需求，还是只做出了要求的页面？
- 数据与权限边界是否合理？敏感信息会不会流向错误位置？
- 是否考虑了异常、空值、重复请求和过期数据？
- 测试是在验证行为，还是只重复代码自身的假设？
- 是否增加了依赖、维护负担或不必要的抽象？
- 六个月后，团队还能读懂并修改这段代码吗？
模型可以帮助思考这些问题，但接受答案不等于验证答案。
为什么凭感觉编程不能成为生产策略？
快速试写代码有助于制作原型、验证想法和获取早期反馈。问题在于原型转为生产系统时，不确定性仍被保留。若不理解代码、缺乏验收标准和测试就上线，速度优势可能变成累积风险。
对于身份认证、支付、个人数据、权限、删除和外部系统自动操作，“看起来能用”不足以作为验收标准。生产错误不仅是页面上的问题，也可能造成数据丢失、安全漏洞或错误客户交易。
有控制机制的AI辅助开发流程
- 用文字明确任务。 明确目标、范围之外的内容、现有行为和验收标准，不让模型自行编造缺失的上下文。
- 先明确方法。 对于较大变更，先要求梳理文件、依赖、风险和小步计划，而不是直接要代码。检查并修订计划后再实施。
- 保持小步变更。 聚焦单一职责的变更更容易验证和回退，不要让模型修改无关文件。
- 一开始就明确测试要求。 除了正常流程，也要定义错误与边界情况，并确认测试在实际环境中确实运行。
- 进行独立审查。 不要只问同一个模型“对不对”来验证结果，应结合代码审查、类型与静态检查，以及安全扫描。
- 分阶段发布。 明确预发布环境、功能开关、监控与回退方式。对外部产生实际影响的自动化，应加入人工审批。
- 明确数据与成本边界。 团队应明确哪些敏感信息可发送给哪些工具，以及访问权限和模型/API成本边界。
不该使用AI的情况
若需求不明、数据未分类或结果不可衡量，应先补齐这些空白。不要把不可逆或高影响决策完全交给自主流程。每个任务都加模型不等于高效；简单规则、SQL查询或小型自动化可能更便宜、更可靠。
AI工具是否可靠，不能只看模型，还要看任务范围、访问权限、上下文和验证机制。“AI写的”不是质量标签，“人写的”也不是质量保证。关键是团队能否理解变更，并通过验证证明它可用。
优秀开发者，并不意味着反对AI
发挥AI的价值，不需要执着于每行代码都亲手完成。把重复工作交给工具，可以让人专注于产品决策、架构、测试和用户影响。但开发者仍需主导过程，不能把模型当成天然知道下一步该做什么的神奇同事。
对我而言，好的AI辅助开发意味着明确任务、有限权限、小步变更、有效测试、人工审查和回退机制。缺少这些基础，软件未必更快变好，只会更快变得难以理解。
如果团队已经使用AI，却不清楚哪些任务可放心交给它、如何验证结果、如何衡量质量，我可以先评估现有开发流程。