近年来,关于如何与人工智能协作的建议越来越多:把问题拆分得更细、把提示写得更精确、选择合适的模型并不断迭代提示。这样的建议并非全错,但它容易把工程师带入一个陷阱,让人以为编程可以完全通过"用英语编程"来完成。真实的工程世界并不接受这种假设。真正有效的做法是把手伸进代码库,写该死的代码,然后再用 AI 做加速与补偿。 将编程视为纯粹的提示工程会带来哪些问题?首先,你的目标从"把软件做好"变成了"把提示写好"。这种目标的错位会削弱工程师的主动性,让人更依赖黑箱工具的完美表现。
其次,提示迭代的成本并不低。每次试验、每次等待和每次微调都会消耗时间,而这些时间本可以用来写一个简单的可运行原型来快速验证想法。第三,自动生成的代码往往缺乏对域知识、架构约束和非功能需求的深刻理解,需要人工去补救与改造。 那么该如何平衡人工智能带来的便利与工程师应有的主动性?核心在于把 AI 当作工具,而非替代。用 AI 帮你做重复性、机械性或辅助性的工作,用你的大脑和双手完成设计决策、关键逻辑和安全边界的实现。一个实用的心态是:先写代码,再用 AI 改进代码;先写关键路径,再让 AI 补全外围;先实现可运行的最小版本,再用 AI 拓展功能。
具体可操作的工作流程并不复杂,也不需要复杂的提示技巧。首先,可以请求 AI 生成一个初始版本以便快速看到整体轮廓,然后把这个版本下载到本地并运行。这个"快速原型"能暴露接口设计、数据流和边界条件的若干问题。接着,闭上编辑器,亲自实现关键逻辑和最容易出错的部分,用单元测试和集成测试保护这些核心代码。AI 在这一阶段可以被用来生成测试用例、编写文档、提取 TODO 列表或做性能建议,但不要把关键决策完全交给它。 另一种常见且高效的做法是先由工程师写一个初始版本,然后请 AI 扮演代码审查者的角色。
把你写的实现贴给 AI,让它帮助发现潜在的边界情况、可读性问题或潜在的性能瓶颈。这种"人先写、AI 后审"的流程能显著提高代码质量,同时也让工程师在与 AI 交互时更有底气。AI 给出的建议不总是正确的,但它能用作补充思路或替代方案,工程师负责判断其可行性并整合到代码中。 还有一种灵活的混合方式是"关键部分人工实现,余下由 AI 填充"。在设计一个系统时,总有一些核心算法、并发模型或安全检查必须由有经验的工程师亲自落地。把这些核心点手写并测试后,把非关键、可重复的代码片段交给 AI 生成。
AI 在生成 CRUD、表单验证、序列化和文档注释等重复性工作时非常擅长,这能显著节省时间并降低人为低级错误。 把 AI 用于写 outline(大纲),让它替你填充细节也是很实用的策略。先设计好文件结构、模块边界和接口签名,然后请 AI 根据这些约束补全函数体或生成示例。这样的方式既保留了工程师对架构的掌控权,又能把零碎代码编写的工作外包给 AI。关键在于把接口和契约写清楚,明确输入输出和不变条件,这样生成的代码更容易被整合和验证。 质量保障不能交给提示反复试验来替代。
和人类一样,AI 生成的代码也会犯低级错误、忽视边缘情况或使用不安全的模式。因此,把自动化测试、静态分析和安全扫描作为工作流的一部分至关重要。写单元测试和端到端测试不仅能捕捉错误,还为重构提供安全网。把测试当作开发的一部分,而不是事后附加的任务,能显著提高你用 AI 协作时的可靠性。 代码所有权与可维护性同样重要。生成代码后不要当成黑箱直接合入版本库。
把生成的片段审阅、重命名并用你的编码风格重构,确保它遵循团队约定和架构原则。对第三方或生成的依赖做许可与合规检查,特别是在商业项目中,避免知识产权风险。同时把 AI 生成的代码加上适当的注释和设计意图说明,帮助未来的维护者理解为何这样实现。 在安全与隐私方面要格外小心。向公共模型发送敏感的业务逻辑、密钥或个人数据存在泄露风险。在这种情况下,优先使用内部模型、私有部署或本地化运行的辅助工具。
对生成的代码进行安全审计,尤其关注不正确的输入校验、错误处理不当或不安全的默认值。把安全设计与威胁建模放在早期,而不是等到人工智能生成代码后做补救。 工程师应当把注意力放在解决真正的复杂性上。编程的价值往往体现在对系统复杂性和不确定性的管理,而不仅仅是把函数撸出来。用 AI 来处理样板代码和重复性任务,把脑力资源集中在需求建模、性能考量、可观测性设计和错误恢复策略上。能否在充满不确定性的环境中快速做出正确的权衡,才是高级工程师的核心竞争力。
工具选择和模型匹配也需要策略性思考。不同模型在生成代码、理解上下文或生成自然语言说明方面各有强项。把复杂逻辑的推理和长期上下文保留给能够处理大上下文窗口的模型,把低延迟的自动补全留给编码型助手。了解工具的局限性并据此分配任务,能有效减少试错成本。 持续集成与持续部署(CI/CD)应当与 AI 协作流程紧密结合。把 AI 生成的变更通过自动化流水线跑测试、构建镜像并进行静态分析,这样可以在合并前捕捉大部分问题。
把模型生成的变更视为任何外部补丁,必须经历同样严格的审核流程。长期看,把生成代码纳入规范化流程比单次依赖更能保障系统稳定性。 心态上的转变也很关键。把 AI 看成是"加速器",而不是"替代者",能让你在职业发展中保持主动。学习如何把 AI 的产出转换为工程资产,从中提取可复用模块、测试用例和文档,这些都是长期积累的财富。不要把技能单纯寄托在写提示上,掌握基础的系统设计、数据结构与算法、调试技巧和架构模式仍旧是不可替代的底层能力。
让 AI 帮你写代码并不是作弊,而是一种生产力工具。关键在于如何将它融入有工程纪律的流程中,避免把复杂性外包给不透明的模型。把握好"先实现最小可运行系统,再用 AI 拓展"的节奏,可以在更短时间内验证假设,同时保留修正方向的能力。通过把核心逻辑亲自实现、用 AI 扩展非关键部分、并对生成内容进行严格测试和审查,工程师能在更短时间内交付更可靠、更可维护的系统。 最后,实践中最有效的训练不是写出无数条提示,而是在真实项目中不断应用混合流程,从成功与失败中总结经验。写些坏代码没关系,重构才是成长的必经之路。
把手伸进代码,写出能跑、能测、能演练的实现,然后再向 AI 寻求帮助。这样的循环会比无休止的提示微调带来更大的生产力收益,也会让你作为工程师的能力持续增长。写代码,别仅仅修炼提示。把 AI 当作最强大的助手,而不是替代你的双手与判断。 现在就开始一个小实验:挑一个你想改进的功能,先在本地实现最小可运行版本,写几条测试,然后让 AI 帮你生成文档、优化性能或补全边缘情况。你会发现,亲自写出的那部分代码为你后续与 AI 的协作奠定了坚实基础,也让整个开发过程更高效、更可控、更有成就感。
。
