---

🚀 关于 XEngineer

XEngineer 新工科计划（原 1024 实训营）由七牛云发起，是一个以开源精神为基石的工程师成长平台。

在 AI 编程工具的冲击下，《人月神话》的传统工程逻辑正在失效，“写代码”不再是核心瓶颈。真正决定项目成败的，变成了更高维度的拷问：

• 你在解决一个真正值得的问题吗？
• 你的系统架构能否支撑未来的变化？
• 你用什么来证明你交付的东西是可靠的？

当 AI 代劳了基础开发，工程师的价值必须向高处迁移：从「代码实现」转向「产品决策与架构设计」。

这正是我们升级为 XEngineer 的初衷——“X”代表倍增，代表跨界，代表正交，代表无限可能，代表我们相信每一位工程师都有潜力创造十倍于过去的价值。

在这里，你将告别纸上谈兵，直面真实复杂的开源项目，体验严谨的工程规范，感受架构设计的艺术，在实战中锻造工程思维，在协作中传承技术精神。

从扎实技术到追求卓越，与我们一起成为 XEngineer。

---

🎯 我们要培养什么样的人？

我们想和你一起成为的，是能够定义问题、设计系统、做出决策、创造商业价值的人。

这样的人，我们称之为：产品架构师（Product Architect）。

支撑这种判断力的，是一套完整的能力框架：

维度	核心问题	本质
工程	怎么把事做成？	拆解复杂问题为独立模块，通过版本迭代逼近目标，借助团队分工协同推进
设计	做什么事？做成什么样子？	一门关于「决策」的学问，回答边界与取舍
商业	什么值得做？	理解需求、衡量价值、判断投入产出

---

🎯 项目特色

• 开源公开：过程公开，结果开源，倒逼高质量产出，让优秀者容易被看见。
• 技术纵深：挑战编程语言、编译器等高技术门槛项目，技术纵深足够，切入点不设限。
• 资深带教：资深专家全程陪跑，代码逐行审阅，架构反复推敲，坚持高工程标准。
• 全流程参与：从定方位到架构设计再到开发实现，体验完整的产品思维和架构思维。
• 小团队共创：5-6 人小组协作，激发潜能，培养团队协作和领导力。

---

📅 8 周硬核迭代旅程 (Milestone Journey)

我们的实战项目采用 8 周 / 4 个里程碑 (Milestone) 的敏捷迭代模式，每一轮都交付可演示的闭环产物：

阶段	核心目标	关键交付物
MS0	开营准备	环境配置、业务议题输入、规范对齐
MS1	战略决策与骨架	产品 Proposal、架构主干代码、首个可串联版本
MS2	MVP 深化落实	核心路径跑通、Issue 任务拆解、架构细化
MS3	功能闭合达标	MVP 完整可用、核心测试覆盖、导师 Code Review
MS4	打磨交付发布	冻结功能、部署环境、v1.0 Tag、路演与复盘

---

🛠 核心工程哲学 (The XEngineer Way)

在 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 原生能力实现全流程可追溯。

📋 实训营工程规范体系（Guidelines and Standards）

为了保证高质量的工程产出，XEngineer 制定了完善的规范矩阵。所有参训学员与开源贡献者均建议阅读：

规范领域	核心关注点	链接
00 软件工程规范	总纲：Milestone 交付标准、协作强制规则、会议与汇报、AI 使用红线	Wiki
01 产品设计规范	提案(Proposal)驱动、做减法、边界清晰、以例子定义行为	Wiki
02 架构设计规范	总架构先行、空骨架代码、模块拆分、架构演进跟踪	Wiki
03 GitHub 过程管理	Milestone/Issue/PR/Release 规范、标签体系、草案评审机制	Wiki

---

🤝 协作与贡献指南 (Contributing)

我们严格遵循 Fork + PR 的原生 GitHub 协作流，拒绝「黑盒式」提交：

1. Issue 先行 — 所有功能与 Bug 必须先建立 Issue。较大需求需在 Issue 中完成 Proposal（产品提案） 的评审。
2. Fork 开发 — Fork 仓库到个人名下，在个人分支进行开发。
3. PR 门禁 — 提交 Pull Request 必须关联对应 Issue，通过测试，可 Review。
4. 强制 Review — 代码必须经过 AI 质量检查与导师 / 助教的人工 Review，确保无方向性偏差且逻辑清晰后方可 Merge。

🏷️ 标签追踪体系：我们使用 proposal → Proposal-Accepted → FullSpec / MiniSpec → Documented 等原生 Label 追踪每一个想法从提出到落地的全生命周期。

⚠️ AI 使用红线：AI 生成的代码，作者必须能完整讲清逻辑。核心架构必须由人设计。每一个 AI 重度参与的 PR 必须附上 Prompt 与人工审查笔记。

---

👁️ 关注我们 (Follow Us)

"不要去盲目追逐变化，相反，要找到不变的东西。你有信心创造出一个 10 年后还不会过时的产品吗？" — 许式伟

XEngineer 新工科计划常年火热招生中。

如果你想持续了解：

• AI 时代工程师的角色将走向何方？
• 什么才是穿越周期的好产品？
• 如何用架构思维做乘法而非加法？

欢迎关注我们的微信公众号【XEngineer新工科计划】，获取最新的项目动态、工程方法论与开源社区资讯。我们在寻找下一批愿意一起回答这些问题的人。

---

📜 许可证 (License)

本组织下的开源项目默认采用 Apache-2.0 或 MIT 开源许可证，具体请参阅各仓库的 LICENSE 文件。

---

_{Initiated by 许式伟 · Powered by Qiniu Cloud ☁️
Rooted in open source, driven by real-world projects, guided by architectural thinking.}