XEngineer 新工科计划（原 1024 实训营）由七牛云发起，是一个以开源精神为基石的工程师成长平台。
在 AI 编程工具的冲击下，《人月神话》的传统工程逻辑正在失效，“写代码”不再是核心瓶颈。真正决定项目成败的，变成了更高维度的拷问：
- 你在解决一个真正值得的问题吗？
- 你的系统架构能否支撑未来的变化？
- 你用什么来证明你交付的东西是可靠的？
当 AI 代劳了基础开发，工程师的价值必须向高处迁移：从「代码实现」转向「产品决策与架构设计」。
这正是我们升级为 XEngineer 的初衷——“X”代表倍增，代表跨界，代表正交，代表无限可能，代表我们相信每一位工程师都有潜力创造十倍于过去的价值。
在这里，你将告别纸上谈兵，直面真实复杂的开源项目，体验严谨的工程规范，感受架构设计的艺术，在实战中锻造工程思维，在协作中传承技术精神。
从扎实技术到追求卓越，与我们一起成为 XEngineer。
我们想和你一起成为的，是能够定义问题、设计系统、做出决策、创造商业价值的人。
这样的人，我们称之为：产品架构师（Product Architect）。
支撑这种判断力的，是一套完整的能力框架：
| 维度 | 核心问题 | 本质 |
|---|---|---|
| 工程 | 怎么把事做成？ | 拆解复杂问题为独立模块，通过版本迭代逼近目标，借助团队分工协同推进 |
| 设计 | 做什么事？做成什么样子？ | 一门关于「决策」的学问，回答边界与取舍 |
| 商业 | 什么值得做？ | 理解需求、衡量价值、判断投入产出 |
- 开源公开：过程公开，结果开源，倒逼高质量产出，让优秀者容易被看见。
- 技术纵深：挑战编程语言、编译器等高技术门槛项目，技术纵深足够，切入点不设限。
- 资深带教：资深专家全程陪跑，代码逐行审阅，架构反复推敲，坚持高工程标准。
- 全流程参与：从定方位到架构设计再到开发实现，体验完整的产品思维和架构思维。
- 小团队共创：5-6 人小组协作，激发潜能，培养团队协作和领导力。
我们的实战项目采用 8 周 / 4 个里程碑 (Milestone) 的敏捷迭代模式，每一轮都交付可演示的闭环产物：
| 阶段 | 核心目标 | 关键交付物 |
|---|---|---|
| MS0 | 开营准备 | 环境配置、业务议题输入、规范对齐 |
| MS1 | 战略决策与骨架 | 产品 Proposal、架构主干代码、首个可串联版本 |
| MS2 | MVP 深化落实 | 核心路径跑通、Issue 任务拆解、架构细化 |
| MS3 | 功能闭合达标 | MVP 完整可用、核心测试覆盖、导师 Code Review |
| MS4 | 打磨交付发布 | 冻结功能、部署环境、v1.0 Tag、路演与复盘 |
在 XEngineer，我们遵循一套严苛但极具价值的工程规范：
- 🎯 先设计，再开发 (Design Before Code)
- 严禁将模糊需求直接丢给 AI 生成代码。任何功能进入编码前，必须先厘清产品边界与架构骨架。
- 📄 文档驱动开发 (Documentation-Driven)
- 重要的决策不留存在聊天记录里。需求变更做增量，工程文档一旦进入开发即视为「只读基线」。
- 🏗️ 代码即架构 (Code as Architecture)
- 系统架构不是目录罗列，而是通过空骨架代码（真实的接口与数据模型，桩实现）以 PR 形式合入主干，确保团队能在稳定的主干上并发开发。
- 🤖 AI-Native 与 人工问责 (AI with Accountability)
- 倡导 Build/Think/Code With AI，让 AI 成为强大伙伴。但坚守红线：AI 不替代工程流程，最终交付责任在人。合入主干的 AI 代码必须经得起拷问，核心逻辑必须有人能完全理解并讲清。
- 🔄 Milestone 敏捷迭代
- 每个 Milestone 都是一轮完整的「产品 → 架构 → 开发」闭环。从 MS1 的战略决策与主干串联，到 MS3 的功能闭合，再到 MS4 的打磨发布，步步为营。
- 🤝 透明且严谨的 GitHub 协作
- 全员采用
Fork + PR模式，Issue 承载工程文档与任务拆解，PR 承载代码与 Review。不额外造轮子，用 GitHub 原生能力实现全流程可追溯。
- 全员采用
为了保证高质量的工程产出，XEngineer 制定了完善的规范矩阵。所有参训学员与开源贡献者均建议阅读：
| 规范领域 | 核心关注点 | 链接 |
|---|---|---|
| 00 软件工程规范 | 总纲：Milestone 交付标准、协作强制规则、会议与汇报、AI 使用红线 | Wiki |
| 01 产品设计规范 | 提案(Proposal)驱动、做减法、边界清晰、以例子定义行为 | Wiki |
| 02 架构设计规范 | 总架构先行、空骨架代码、模块拆分、架构演进跟踪 | Wiki |
| 03 GitHub 过程管理 | Milestone/Issue/PR/Release 规范、标签体系、草案评审机制 | Wiki |
我们严格遵循 Fork + PR 的原生 GitHub 协作流，拒绝「黑盒式」提交：
- Issue 先行 — 所有功能与 Bug 必须先建立 Issue。较大需求需在 Issue 中完成 Proposal（产品提案） 的评审。
- Fork 开发 — Fork 仓库到个人名下，在个人分支进行开发。
- PR 门禁 — 提交 Pull Request 必须关联对应 Issue，通过测试，可 Review。
- 强制 Review — 代码必须经过 AI 质量检查与导师 / 助教的人工 Review，确保无方向性偏差且逻辑清晰后方可 Merge。
🏷️ 标签追踪体系：我们使用 proposal → Proposal-Accepted → FullSpec / MiniSpec → Documented 等原生 Label 追踪每一个想法从提出到落地的全生命周期。
⚠️ AI 使用红线：AI 生成的代码，作者必须能完整讲清逻辑。核心架构必须由人设计。每一个 AI 重度参与的 PR 必须附上 Prompt 与人工审查笔记。
"不要去盲目追逐变化，相反，要找到不变的东西。你有信心创造出一个 10 年后还不会过时的产品吗？" — 许式伟
XEngineer 新工科计划常年火热招生中。
如果你想持续了解：
- AI 时代工程师的角色将走向何方？
- 什么才是穿越周期的好产品？
- 如何用架构思维做乘法而非加法？
欢迎关注我们的微信公众号【XEngineer新工科计划】，获取最新的项目动态、工程方法论与开源社区资讯。我们在寻找下一批愿意一起回答这些问题的人。
本组织下的开源项目默认采用 Apache-2.0 或 MIT 开源许可证，具体请参阅各仓库的 LICENSE 文件。
Initiated by 许式伟 · Powered by Qiniu Cloud ☁️
Rooted in open source, driven by real-world projects, guided by architectural thinking.
让技术成长，从这里开始 ✨
如果这个项目对你有帮助，请给我们一个 ⭐️