最近在 XGo 用户群里，看到许士伟和马工围绕 AI Coding 展开了几轮有意思的讨论。从 10 月 9 日到 13 日，两人在 AI 的本质定位、工作流程、组织变革等话题上碰撞出不少火花。这些讨论不是纯理论的，背后都有真实的实践经验支撑。许士伟团队刚刚在 10 月 12 日发布了 XGo v1.5.2，这是第一个 AI 作为主力程序员参与开发的版本，AI 代号 XGopilot 已经成为项目的第 8 大贡献者。
这篇文章整理了他们的核心观点和分歧，帮助大家了解当前 AI Coding 实践中的不同思路。
10 月 9 日晚，马工抛出一个问题："现在还认为 AI 是软件吗？"暗示 AI 可能已经超越传统软件的范畴。
许士伟的回答很直接："当然啊"，并且批评这是"一个不太有营养的问题"。他给出了清晰的定义：
AI Coding 和 AI 是两码事。AI Coding 属于一类 AI 应用。而 AI 狭义上应该是提供智能的单元本身。
这个定义把讨论拉回到具体的工程实践层面，后续的争论也主要集中在 AI Coding 的应用方式上。
马工关心一个实际问题："你同时在 issue 和 pr 下和它对话，不会乱吗？"他在探索企业级的工程化方案，关注 system prompt 应该放在哪一层（repo 层、公司层还是 persona 层），以及如何管理多个 persona（dev、tester、security engineer）。
许士伟的做法比较简单粗暴：
他反对搞复杂的 spec 规范，主张"用 GitHub 传递上下文，其他都交给 AI"。实战中，他在 XGo 主 repo 里放了一个 CLAUDE.md 作为 AI 的工作指南。
到了 10 月 11 日，马工分享了自己的经验：
设计这个环节，同步模式比较好，它出方案，你现场纠正，feedback loop 短。
许士伟的观察更谨慎：
复杂逻辑的 design，AI 还是想不出特别好的主意，给的方案整体上比较平庸。
他说自己已经纠正了 2 次，AI 表现仍然不理想。这说明 AI 在创造性设计方面还有明显局限。
马工提出一个大胆的想法：
我想挑战这个流程，去掉中间商，销售直接叫研发。
他的设想是，让 To B 公司的销售拥有独立环境和 POC 分支，配合 AI 快速完成客户定制化演示，"一个销售 + 一个工程师 + AI，两个小时就能完成"。
许士伟的反应很强烈：
这个不会成功，公司会乱套了。
他的理由是：
但他也认可 POC 场景："这样可以，只是 POC 没问题"——前提是不进主分支。
两人最终在一个点上达成共识：售前用 AI Coding 快速出 POC 或方案是有价值的。马工说"销售可以带 live demo system 见客户，而不只是 PPT"，许士伟回应"这个和我们思路一样"。
许士伟对 AI 的定位很清楚：
AI 推理能力在人类平均线附近且偏下一点。AI 的优势是几乎没有知识盲区，所以很多看似很难的问题它都能够解答。AI 虽然不够聪明（推理能力），但是足够全能。
他的实践重点：
他还提到一个教育话题：
对中国的教育挑战很大，我们的教育出来的人才和大模型能力重叠度太高。
马工关注的是更大层面的组织变革：
他用 Claude Code 生成 Mermaid 架构图和文档，解决代码文档漂移问题。
| 对比维度 | 许士伟 | 马工 |
|---|---|---|
| 目标 | 编译器开发 + POC | 企业级应用 + 销售赋能 |
| 质量标准 | 高（85%+ 测试覆盖） | 灵活（POC 不进主分支） |
| 工具选择 | 主要用 Claude | Claude Code + 多模型 |
| 流程理念 | 简化，反对复杂 spec | 探索分层 system prompt |
| 组织变革 | 保守（产品经理必须会写代码） | 激进（销售直接用 AI 做 POC） |
这场讨论本质上反映了 AI Coding 应用的两种路径：
许士伟的工匠路线：把 AI 当作高质量的编程助手，保持传统软件工程的严谨性，提升个人和小团队的研发效率。
马工的变革路线：把 AI 当作组织流程重构的催化剂，探索打破传统职能边界的可能性，通过 AI 赋能非技术角色参与技术工作。
两人在 POC 场景上有共识，但在是否用 AI 重构组织流程上存在分歧。许士伟更注重工程质量和可持续性，马工更关注快速响应客户需求和组织敏捷性。
XGo v1.5.2 的发布是一个重要的里程碑，XGopilot 作为第 8 大贡献者已经证明了 AI 可以成为真正的团队成员。接下来值得关注的是，这两种路径会在实践中产生怎样的效果，以及是否会出现更多混合模式。