# \[2026-02-05] 🔥 AI Coding 实战派观点：从「怎么写」到「写什么」 \[2026-02-05] 🔥 AI Coding 实战派观点：从「怎么写」到「写什么」 *** ### 1. 实战检验是唯一标准 > 他们评价现在对 AI Coding 工具好坏与否的唯一标准是能否在真实生产系统落地交付，大厂未经过实战的全套 AI 方案毫无价值。专家指出，全自动 AI 程序员（如 Devin）现阶段完全行不通，易出现需求理解偏差、架构不一致、交付质量不稳定等问题，未来 3-5 年人机协作是企业级开发主流，长期 Agent 才是发展方向。当前，开发工作的核心已从"怎么写"转向"写什么"，从关注代码细节转向业务逻辑、边界条件、异常处理；思考必须更清晰，才能让 AI 准确理解需求。 他们评价现在对 AI Coding 工具好坏与否的唯一标准是能否在真实生产系统落地交付，大厂未经过实战的全套 AI 方案毫无价值。专家指出，全自动 AI 程序员（如 Devin）现阶段完全行不通……当前，开发工作的核心已从"怎么写"转向"写什么"，从关注代码细节转向业务逻辑、边界条件、异常处理；思考必须更清晰，才能让 AI 准确理解需求。 *** ### 2. 方法论：一手信息、亲自实践、主动输出 > 获取一手信息、亲自实践并主动输出观点。不应将 AI 当作全知全能的神，而应让其批判性思考、挑战自身观点，避免强化认知偏见；AI 的核心价值是成为既支持又挑战人类的协作对象。 见全文方法论部分。 *** ### 3. 三种不可替代的能力 > 松子：如果没有 AI，我几乎一行代码都写不出来。但我认为我的价值并不在于是否能逐行写代码，而在于：第一，我清楚自己要做什么；第二，我能够判断 AI 给出的方案是否可靠；第三，我能把需求描述清楚。这三种能力，是 AI 目前无法替代的。 松子：如果没有 AI，我几乎一行代码都写不出来。但我认为我的价值并不在于是否能逐行写代码，而在于：第一，我清楚自己要做什么；第二，我能够判断 AI 给出的方案是否可靠；第三，我能把需求描述清楚。这三种能力，是 AI 目前无法替代的。 *** ### 4. AI 管理学：流程和思路 > 流程和思路。马工：我并不把 AI 当作一个工具，而是把它当作一个同事。我和朋友一起探索出了一套理论，叫作 AI 管理学。传统管理里有人力资源管理，而现在我认为还需要一套面向 AI 的管理体系。管理的核心从来不在于工具本身，而在于流程和思路，也不存在所谓"最优解"。对我来说，更重要的是探索出一套适合自己的 AI 管理方法，并与我的工具组合在一起，形成最适合产品的方式。 马工：我并不把 AI 当作一个工具，而是把它当作一个同事……管理的核心从来不在于工具本身，而在于流程和思路，也不存在所谓"最优解"。 *** ### 5. 噱头与实践是两码事 > 不谋而合，噱头和实践完全是两码事。尤其在当前 AI 的浪潮下，营销力度已经到了夸张的地步。 所以我现在评估工具，只看一件事：有没有在真实生产系统中、处理过真金白银的案例。如果没有，我基本不相信。也正因为如此，我现在比较反感一些大厂的做法，声称做出了一整套方案，要求别人直接照着用。但我仔细看过之后发现，他们自己甚至没有用这些工具真正做出一个在生产环境中运行、处理真实业务的系统。 *** ### 6. 工程意味着可读性、可维护性 > 工程意味着可读性，可维护性。AI 无法解决的问题，人类将是最后一道防线。 张汉东：从产品经理背景转过来的用户，使用 Vibe Coding 时，往往并不太关心底层代码质量，更关注功能是否完整、是否可用。像我这种程序员出身的人，会不可避免地带着一些工程习惯，更在意代码质量、可维护性。因此在使用这种对话式代码生成工具时，我需要对整体生成逻辑进行把控。 *** ### 7. 钢铁与海绵的比喻 > 这个比喻不错。 张汉东：一般来说，一个产品上线之后，后续一定涉及维护。如果形成的是一个"AI 生成代码、AI 修 bug"的闭环，短期内是可以工作的。但随着用户规模和代码规模不断扩大，很容易陷入不可控状态，最终变成一次性应用，用完即弃。对于一些关键领域，比如基础设施或操作系统，使用 Vibe Coding 时，你需要的是钢铁般稳定的结构；而在一些不那么关键的上层应用场景中，可以接受"用完即弃"，我更愿意把这种代码形态比作海绵结构，内部存在不少空隙和不确定性。最终可能呈现的是一种"海绵包裹钢铁"的混合结构。 *** ### 8. 大模型解耦 > 大模型解耦。 至于具体用哪个模型、哪个工具，在我的理论体系里并不是关键问题。我可以随时切换到其他大模型，最多只是质量稍差一些，或者返工次数多一些。这也是我和很多朋友共同追求的目标：构建一套尽量与具体大模型解耦、依赖度很低的 AI 团队体系。 *** ### 9. 日抛与生产：Demo 用完即弃 > 日抛与生产。 松子：Lovable 是我去年刚开始用大模型编程时常用的工具……但我当时犯了一个很大的错误，就是在 live demo 之后，直接尝试把 demo 代码演进成生产级代码，结果掉进了一个非常深的坑。后来我逐渐形成了一种方法：live demo 结束后，先进入"包头"状态，对代码做一次完整重构。把 demo 代码直接拿去改成生产级，几乎就是一场灾难。demo 能跑、能看，但架构往往一塌糊涂，在其基础上继续加功能，重构成本甚至比重写还高。所以我的原则是，demo 用完即弃，属于日抛型产物，只用于表达和验证想法。 马工：过去和客户的交互往往需要研发团队支持，现在有了这些非专业编程工具，销售可以自己完成，整体效率提升非常明显。所以我并不完全同意"Lovable 不能用于生产"这种说法。比如销售做一个 demo，本身就是生产，它在业务上的价值，可能比我写一个非常复杂、可扩展的系统还要高。它能够直接促成订单，那为什么不能算生产呢？ *** ### 10. 所用之物与所做之事 > 又让我想起了那个 SICP 的课里老师所说的所用之物和所做之事的区别了。 王一鹏：Karpathy 说 AI 在"可验证任务"（如代码、数学）上可能超越人类专家，但在"不可验证任务"（如架构设计、战略决策）上进展缓慢。你们觉得 AI 什么时候能真正理解什么是"优雅的架构"？还是永远不能？ 马工：作为工程师，我的核心目标只有一个，就是把问题解决掉。这个问题是用 AI 来解决，还是让同事解决，或者交给软件系统解决，对我来说本质上都只是工具选择而已。 *** ### 11. 50-30-20 时间分配：从写代码到架构思维 > 50% 的时间在和 AI 对话，30% 的时间审查 AI 生成的代码，剩下 20% 用于调试。这并不是降级，而是一种升级，从写代码转向架构和产品思维。 在技术实现能力上，AI 确实在拉平差距，很多工程师的实现能力被 AI 显著拉近了。但需求表达能力反而成了一种稀缺资源。我们合作的一家央企，原来的"技术团队"已经改名为"需求经理"，他们大约 50% 的时间在和 AI 对话，30% 的时间审查 AI 生成的代码，剩下 20% 用于调试。这并不是降级，而是一种升级，从写代码转向架构和产品思维。 从"怎么写"转向"写什么"，从一次性完成转向迭代逼近……同时，还有一个明显变化：以前自己想明白就够了，现在必须让 AI 也想明白，这反而倒逼自己的思考更加清晰。在我看来，AI 时代最核心的能力不是写代码，而是把需求说清楚；说不清楚，AI 就会用一堆 bug 来"教育你"。 *** ### 12. 永不过时的批判性思维 > 永不过时的批判性思维。 马工：我在 ChatGPT 里做了定制化设置，明确要求它进行批判性思考、挑战我的观点、不清楚就不要回答，所有结论都必须有来源。我甚至在"塑造"AI 的性格，因为 AI 很容易顺着用户说话，而我刻意要求它不要强化我的偏见，而是帮助我识别并修正偏见。你不能把 AI 当成一个全知全能的神来崇拜，否则一旦结果不符合预期，就会迅速失望并转而寻找"下一个神"。 你之所以向 AI 求助，本身就说明你的认知是有限的，如果 AI 只是顺着你说，只会加固你的局限。你真正需要的是一个既支持你、又挑战你的对象，让你意识到自己可能是错的，甚至从根本上重新审视需求或架构。 *** ### 13. 判断代码好坏的价值被放大 > AI 拉平了"会写代码"的价值，却显著放大了"判断代码好坏"的价值。 松子：入门门槛确实被大幅降低了，同时精通的门槛也被拉低，但天花板却被抬得更高了……另一个重要变化是中间层的塌陷。过去依靠手速和熟练度生存的那一层工程师，正在被 AI 快速替代。入门者可以借助 AI 很快学会写代码，而中间层却被压缩消失。反而是依靠架构能力和判断力的资深工程师，在 AI 时代变得更加稀缺。AI 拉平了"会写代码"的价值，却显著放大了"判断代码好坏"的价值。因此，我认为 AI 时代最危险的并不是不懂代码，而是以为自己已经懂了。 *** ### 14. 一手信息、亲自实践、主动输出 > 一定要获取一手信息，不要只看公众号，不要只接受别人咀嚼过的结论。亲自动手的成本其实很低，只要你自己去实践，就会获得与他人完全不同的体验，通过不断对比，你才能逐渐和别人站在同一水平线上。 我现在特别想做的一件事，是重新构建一套话语体系……如果一个年轻人有足够的胆量，想成为新时代的软件工程思想领军人物，现在就是最合适的窗口期，可能只有一到两年，必须立刻行动。一定要获取一手信息，不要只看公众号，不要只接受别人咀嚼过的结论。亲自动手的成本其实很低，只要你自己去实践，就会获得与他人完全不同的体验，通过不断对比，你才能逐渐和别人站在同一水平线上。 松子：AI 编程正在成为标配，已经不再是加分项，而是基础能力……归结为一句话，就是要放下对手工写代码的执念，从"敲键盘"转向"拿指挥棒"。在 2026 年，真正具备竞争力的，不是单纯写代码的人，而是能够指挥 AI 写代码、并把握方向的人。 *** ### AI 总结分析 这篇对话记录了三位 AI Coding 实践者（松子、马工、张汉东）的深度交流，批注者敏锐地捕捉到了几个核心洞见： **1. 实战为王**：评价 AI 工具的唯一标准是「真金白银的生产案例」，大厂的 PPT 方案毫无价值。这与批注者「噱头与实践是两码事」的判断高度一致。 **2. 能力重构**：从「怎么写」到「写什么」的转变，意味着三种不可替代的能力——知道要做什么、判断方案可靠性、清晰表达需求。50-30-20 的时间分配（对话-审查-调试）是这种转变的具体体现。 **3. 架构隐喻**：「钢铁包裹海绵」的比喻精准描述了 AI 时代代码的双层结构——关键基础设施需要钢铁般稳定，上层应用可以接受「日抛」。Demo 与生产的边界需要清晰划定。 **4. 批判性协作**：AI 不应是「全知全能的神」，而应是「既支持又挑战」的协作对象。主动设置 AI 挑战自己的观点，避免认知偏见被强化。 **5. 中间层塌陷**：AI 拉平了「会写代码」的价值，却放大了「判断代码好坏」的价值。依靠手速和熟练度的中间层工程师正在被替代，架构能力和判断力成为稀缺资源。 **6. 行动窗口**：获取一手信息、亲自实践、主动输出——这是批注者反复强调的方法论。当前是成为「新时代软件工程思想领军人物」的窗口期，只有一到两年。 批注者与 SICP「所用之物与所做之事」的联想，点出了更深层的哲学问题：AI 擅长「可验证任务」，但「不可验证任务」（架构设计、战略决策）仍需人类判断。这正是「大模型解耦」思想的底层逻辑——工具可以换，但判断力不可替代。 *** ### 原文 * **来源**：InfoQ * **标题**：（原文标题未在输入中提供，链接为 * **作者**：王一鹏（主持）、松子、马工、张汉东（对话嘉宾）