|
| 1 | +# 1024 实训营课程体系设计 |
| 2 | + |
| 3 | +## 设计理念 |
| 4 | + |
| 5 | +基于"成就优秀工程师"的愿景,1024 实训营采用"定方向-做架构-做实现"三大模块的课程体系,旨在培养具备产品思维、架构思维和工程实现能力的复合型工程师。在 AI 重构开发范式的时代背景下,我们更注重培养学员的元决策能力和系统思维,而非简单的代码编写技能。 |
| 6 | + |
| 7 | +**创客 PBL 模式融入**:我们借鉴创客空间(Maker Space)和项目式学习(Project-Based Learning)的理念,强调"做中学"、"协作共创"、"迭代改进"的学习模式,让学员在真实项目实践中获得成长。 |
| 8 | + |
| 9 | +## 课程体系概览 |
| 10 | + |
| 11 | +### 第一阶段:定方向(第 1-4 周) |
| 12 | + |
| 13 | +**目标:培养产品思维,学会定义问题和价值** |
| 14 | + |
| 15 | +#### 核心能力培养 |
| 16 | + |
| 17 | +- **需求分析能力**:学会从用户视角理解问题,识别真实需求 |
| 18 | +- **产品思维**:理解技术如何创造商业价值 |
| 19 | +- **价值定义能力**:学会评估技术方案的价值和优先级 |
| 20 | + |
| 21 | +#### 具体内容 |
| 22 | + |
| 23 | +1. **产品需求调研与分析** |
| 24 | + |
| 25 | + - 竞品分析方法 (一张表诉所有) |
| 26 | + - 功能对比矩阵:列出核心功能点,对比各竞品的实现情况 |
| 27 | + - 技术架构分析:研究竞品的技术选型和架构设计 |
| 28 | + - 用户体验分析:从用户角度体验竞品,记录优缺点 |
| 29 | + - 差异化定位:识别竞品的特色功能和市场定位 |
| 30 | + |
| 31 | +2. **产品设计思维** |
| 32 | + |
| 33 | + - 思维理念 (初级产品经理喜欢做加法,顶级产品经理做的是减法) |
| 34 | + - 做减法思维:从加法到减法的转变 |
| 35 | + - 精准定位:减到刚好精准命中用户心智 |
| 36 | + - 价值聚焦:识别核心价值,避免功能堆砌 |
| 37 | + - 用户思维 |
| 38 | + - 以用户为中心:从用户视角思考问题 |
| 39 | + - 用户旅程地图:理解用户使用产品的完整流程 |
| 40 | + - 同理心设计:站在用户角度感受痛点和需求 |
| 41 | + - 数据思维 |
| 42 | + - 数据驱动决策:基于数据而非直觉做产品决策 |
| 43 | + - 关键指标定义:识别产品的核心成功指标 |
| 44 | + - A/B 测试思维:通过实验验证产品假设 |
| 45 | + - 迭代思维 |
| 46 | + - 快速试错:小步快跑,快速验证 |
| 47 | + - 持续优化:基于反馈不断改进产品 |
| 48 | + - 版本规划:合理规划产品迭代节奏 |
| 49 | + |
| 50 | +#### 交付物 |
| 51 | + |
| 52 | +- **竞品分析文档**:包含功能对比矩阵、技术架构分析、用户体验分析、差异化定位等内容的完整竞品分析报告 |
| 53 | +- **产品需求文档(PRD)**:详细的产品需求描述,包含用户故事、功能规格、验收标准等 |
| 54 | +- **产品原型设计**:低保真或高保真的产品原型,用于验证产品概念和用户流程 |
| 55 | +- **技术可行性评估报告**:对技术方案的可行性、成本效益、风险评估的初步分析 |
| 56 | + |
| 57 | +--- |
| 58 | + |
| 59 | +### 第二阶段:做架构(第 5-8 周) |
| 60 | + |
| 61 | +**目标:培养架构思维,学会系统设计** |
| 62 | + |
| 63 | +#### 核心能力培养 |
| 64 | + |
| 65 | +- **系统思维**:理解复杂系统的整体性和关联性,学会从业务角度看待模块拆解 |
| 66 | +- **架构设计能力**:学会设计可扩展、可维护的系统架构,重点在于模块边界定义和资产设计 |
| 67 | +- **技术决策能力**:在多种技术方案中做出合理选择,基于价值=需求量 × 单价的商业思维 |
| 68 | + |
| 69 | +#### 具体内容 |
| 70 | + |
| 71 | +1. **架构设计基础** |
| 72 | + |
| 73 | + - **模块拆解思维**:学会将复杂系统拆解为独立的业务模块 |
| 74 | + |
| 75 | + - 每个模块都是独立的业务,有独立的需求边界和价值 |
| 76 | + - 模块边界设计:明确每个模块解决什么问题、不解决什么问题 |
| 77 | + - 资产设计:定义模块间的输入/输出资产,资产决定一切 |
| 78 | + - AI 辅助:使用 AI 工具分析系统复杂度,辅助模块拆解决策 |
| 79 | + |
| 80 | + - **连接与组合设计** |
| 81 | + - 实体边界问题:程序、动态库、包、模块、函数等实体的边界定义 |
| 82 | + - 模块间接口设计:如何连接和组合不同的模块 |
| 83 | + - 依赖关系管理:避免过度耦合,保持模块独立性 |
| 84 | + - AI 辅助:利用 AI 分析模块间依赖关系,识别潜在耦合问题 |
| 85 | + |
| 86 | +2. **技术方案评估** |
| 87 | + |
| 88 | + - **需求分析深度**:不是简单罗列需求,而是洞察需求的内在逻辑关联 |
| 89 | + |
| 90 | + - 需求发展方向预判:防止过度设计 |
| 91 | + - 需求逻辑关联分析:找到代价最低的实现路径 |
| 92 | + - 实体提炼:用实体来描述需求,建立需求间的关联 |
| 93 | + - AI 辅助:使用 AI 分析需求间的逻辑关联,辅助实体提炼 |
| 94 | + |
| 95 | + - **技术可行性分析**:评估技术方案的实现难度 |
| 96 | + - **成本效益分析**:开发成本 vs 预期收益 |
| 97 | + - **技术风险识别**:识别潜在的技术风险点 |
| 98 | + - **替代方案对比**:对比不同技术方案的优劣 |
| 99 | + - AI 辅助:利用 AI 进行多方案对比分析,生成技术选型建议 |
| 100 | + |
| 101 | +3. **性能与可扩展性设计** |
| 102 | + |
| 103 | + - 架构层面的性能考虑:理解性能瓶颈的常见位置 |
| 104 | + - 可扩展性设计原则:如何设计支持业务增长的架构 |
| 105 | + - 技术选型的性能影响:不同技术方案对性能的影响评估 |
| 106 | + - AI 辅助:使用 AI 进行性能瓶颈分析,优化架构设计 |
| 107 | + |
| 108 | +4. **架构落地实践** |
| 109 | + |
| 110 | + - **代码模块规格设计** |
| 111 | + |
| 112 | + - 模块接口定义:明确的输入输出规格 |
| 113 | + - 模块职责边界:每个模块的独立价值定位 |
| 114 | + - 模块间契约:模块如何协作的明确约定 |
| 115 | + - AI 辅助:利用 AI 生成模块接口规范,确保接口设计的一致性 |
| 116 | + |
| 117 | + - **模块串联实现** |
| 118 | + |
| 119 | + - 连接性代码编写:实现模块间的连接逻辑 |
| 120 | + - 资产流转设计:确保资产在模块间稳定传递 |
| 121 | + - 错误处理机制:模块间异常情况的处理策略 |
| 122 | + - AI 辅助:使用 AI 生成连接性代码模板,提高开发效率 |
| 123 | + |
| 124 | + - **架构演进管理** |
| 125 | + - 模块重构策略:如何在不破坏整体架构的前提下优化模块 |
| 126 | + - 向后兼容性:确保架构演进不影响现有功能 |
| 127 | + - 性能优化:在架构层面进行性能调优 |
| 128 | + - AI 辅助:利用 AI 分析架构演进影响,生成重构建议 |
| 129 | + |
| 130 | +#### 交付物 |
| 131 | + |
| 132 | +- **系统架构设计文档**:详细的系统架构设计,包含架构图、模块划分、接口定义等 |
| 133 | +- **模块规格说明书**:每个模块的详细规格定义,包含接口、职责、边界等 |
| 134 | +- **模块串联设计文档**:模块间如何连接和组合的详细设计 |
| 135 | +- **技术选型报告**:技术栈选型的详细分析和决策过程 |
| 136 | +- **技术方案评估报告**:多方案对比分析,包含可行性、成本效益、风险评估 |
| 137 | +- **架构评审记录**:团队架构评审的讨论记录和决策过程 |
| 138 | +- **代码实现验证**:通过实际代码实现验证架构设计的可行性 |
| 139 | + |
| 140 | +--- |
| 141 | + |
| 142 | +### 第三阶段:做实现(第 9-12 周) |
| 143 | + |
| 144 | +**目标:培养设计驱动开发能力,学会高质量交付** |
| 145 | + |
| 146 | +#### 核心能力培养 |
| 147 | + |
| 148 | +- **设计驱动能力**:学会通过精确的设计指导 AI 生成高质量代码 |
| 149 | +- **代码规范意识**:追求极致的代码质量和工程规范 |
| 150 | +- **AI 协作能力**:学会与 AI 高效协作,提升开发效率 |
| 151 | + |
| 152 | +#### 具体内容 |
| 153 | + |
| 154 | +1. **设计驱动开发实践** |
| 155 | + |
| 156 | + - **精确设计规范** |
| 157 | + |
| 158 | + - 接口设计规范:如何设计清晰、一致的 API 接口 |
| 159 | + - 数据结构设计:如何设计高效、可扩展的数据结构 |
| 160 | + - 算法设计规范:如何设计正确、高效的算法 |
| 161 | + - AI 辅助:使用 AI 验证设计方案的合理性和完整性 |
| 162 | + |
| 163 | + - **AI 代码生成与优化** |
| 164 | + - 设计到代码的转换:如何将设计规范转化为 AI 指令 |
| 165 | + - 代码生成策略:分模块、分层次的代码生成方法 |
| 166 | + - 代码质量检查:确保 AI 生成代码符合工程规范 |
| 167 | + - AI 辅助:利用 AI 进行代码质量分析和优化建议 |
| 168 | + |
| 169 | +2. **工程规范与最佳实践** |
| 170 | + |
| 171 | + - **代码规范与风格指南** |
| 172 | + |
| 173 | + - 命名规范:变量、函数、类的命名规则 |
| 174 | + - 代码结构规范:模块组织、文件结构的最佳实践 |
| 175 | + - 注释规范:如何编写清晰、有用的代码注释 |
| 176 | + - AI 辅助:使用 AI 工具自动检查和修复代码规范问题 |
| 177 | + |
| 178 | + - **版本控制与协作流程** |
| 179 | + - Git 工作流程:分支管理、提交规范 |
| 180 | + - Code Review 流程:设计评审、代码评审的标准流程 |
| 181 | + - 协作规范:团队协作中的沟通和决策机制 |
| 182 | + - AI 辅助:利用 AI 辅助代码评审,提高评审效率 |
| 183 | + |
| 184 | +3. **质量保障体系** |
| 185 | + |
| 186 | + - **测试策略设计** |
| 187 | + |
| 188 | + - 测试用例设计:如何设计全面、有效的测试用例 |
| 189 | + - 测试覆盖策略:单元测试、集成测试、端到端测试的平衡 |
| 190 | + - 自动化测试:如何设计可维护的自动化测试 |
| 191 | + - AI 辅助:使用 AI 生成测试用例,提高测试覆盖率 |
| 192 | + |
| 193 | + - **代码质量监控** |
| 194 | + - 静态代码分析:使用工具进行代码质量检查 |
| 195 | + - 性能监控:关键性能指标的监控和分析 |
| 196 | + - 安全审查:代码安全漏洞的识别和修复 |
| 197 | + - AI 辅助:利用 AI 进行代码质量评估和安全分析 |
| 198 | + |
| 199 | +#### 交付物 |
| 200 | + |
| 201 | +- **设计规范文档**:详细的设计规范和标准,包含接口设计、数据结构设计等 |
| 202 | +- **AI 协作指南**:与 AI 协作的最佳实践和工具使用指南 |
| 203 | +- **完整的项目代码库**:包含所有源代码、配置文件、测试代码的完整项目 |
| 204 | +- **代码质量报告**:详细的代码质量评估和优化建议 |
| 205 | +- **测试策略文档**:测试用例设计、测试覆盖策略的详细文档 |
| 206 | +- **项目总结报告**:项目开发过程的总结和经验分享 |
| 207 | +- **个人成长记录**:个人在项目中的成长轨迹和技能提升记录 |
| 208 | + |
| 209 | +## 实训营特色模式 |
| 210 | + |
| 211 | +### 1. 真实项目实践(Real Project Practice) |
| 212 | + |
| 213 | +**真实项目场景**:每个学员都参与真实的开源项目开发,而非模拟练习, 如: |
| 214 | + |
| 215 | +- **XGo 编译器项目**:参与编程语言底层技术开发 |
| 216 | +- **Go+ Builder 项目**:构建可视化编程教育平台 |
| 217 | + |
| 218 | +**问题导向**:从真实的技术问题出发,激发学习动机, 如: |
| 219 | + |
| 220 | +- 如何基于 AI 构建智能运维能力 |
| 221 | +- 如何降低 Go+ Builder 的使用门槛? |
| 222 | +- 如何优化 XGo 编译器的类型推导机制? |
| 223 | + |
| 224 | +### 2. 团队协作学习(Team Collaboration Learning) |
| 225 | + |
| 226 | +**跨角色协作**:不同技术背景的学员组成团队(前端、后端、算法等) |
| 227 | + |
| 228 | +**知识共享机制**: |
| 229 | + |
| 230 | +- **技术分享会**:每周进行技术分享? |
| 231 | +- **代码评审会**:定期进行代码评审和最佳实践讨论 |
| 232 | +- **问题解决工作坊**:针对共性问题进行集体攻关 |
| 233 | + |
| 234 | +### 3. 迭代改进学习(Iterative Learning) |
| 235 | + |
| 236 | +**快速原型**:鼓励学员快速构建原型,验证想法 |
| 237 | + |
| 238 | +**持续反馈**: |
| 239 | + |
| 240 | +- **导师反馈**:定期获得导师的技术指导和建议 |
| 241 | +- **同伴反馈**:通过代码评审获得同伴的建议 |
| 242 | +- **用户反馈**:通过实际使用获得真实用户反馈 |
| 243 | + |
| 244 | +### 4. 开源社区融入(Open Source Integration) |
| 245 | + |
| 246 | +**过程开源**:所有项目代码都开源到 GitHub |
| 247 | + |
| 248 | +- 阶段性成果在技术社区分享 |
| 249 | +- 经验总结与技术博客输出 |
| 250 | +- 开源贡献作为个人技术名片 |
| 251 | +- 持续维护:毕业后继续参与项目维护和迭代 |
| 252 | + |
| 253 | +**技术博客输出**: |
| 254 | + |
| 255 | +- 经验总结:将学习过程中的经验总结为技术博客 |
| 256 | +- 知识分享:通过技术分享帮助更多人学习 |
| 257 | +- 个人品牌:建立个人技术品牌和影响力 |
| 258 | + |
| 259 | +### 5. 行业大咖指导(Industry Expert Guidance) |
| 260 | + |
| 261 | +**导师规范**: |
| 262 | + |
| 263 | +- 任务以书面形式明确给出 |
| 264 | +- 讨论内容沉淀为文档 |
| 265 | +- 定期技术分享与经验交流 |
| 266 | +- 个性化成长指导 |
| 267 | + |
| 268 | +**行业大咖分享**: |
| 269 | + |
| 270 | +- 邀请技术大咖进行专题讲座 |
| 271 | +- 直播分享与互动交流 |
| 272 | +- 短视频内容制作与分发 |
| 273 | +- 导师经验分享与技术答疑 |
| 274 | + |
| 275 | +## 工程习惯培养 |
| 276 | + |
| 277 | +### 基于 PR 的开发协作流程 |
| 278 | + |
| 279 | +推荐采用基于 PR(Pull Request)的开发协作流程,每个 PR 都应该包含: |
| 280 | + |
| 281 | +- **问题背景**:为什么要做这个改动 |
| 282 | +- **参考依据**:基于什么考虑做出这个决策 |
| 283 | +- **方案对比**:考虑了哪些方案,各自的优劣 |
| 284 | +- **最终决策**:为什么选择当前方案 |
| 285 | +- **预期效果**:期望达到什么样的效果 |
| 286 | + |
| 287 | +### Code Review Comments 沉淀机制 |
| 288 | + |
| 289 | +为了形成有实训营风格的写代码规范,我们建立以下机制: |
| 290 | + |
| 291 | +- **Issue 记录 PR Comments**:每个 PR 的 review comments 都要记录在对应的 Issue 中 |
| 292 | +- **决策过程文档化**:将 review 过程中的讨论、决策、权衡都沉淀为文档 |
| 293 | +- **最佳实践总结**:定期总结 review 中发现的共性问题,形成最佳实践指南 |
| 294 | +- **规范迭代优化**:基于 review 反馈持续优化代码规范和开发流程 |
| 295 | + |
| 296 | +### 代码规范要求 |
| 297 | + |
| 298 | +- 严格的代码风格检查 |
| 299 | +- 完整的单元测试覆盖 |
| 300 | +- 详细的代码注释和文档 |
| 301 | +- 定期的代码质量评估 |
| 302 | + |
| 303 | +## 实训营评估体系 |
| 304 | + |
| 305 | +### 过程性评估(Process Assessment) |
| 306 | + |
| 307 | +**学习过程记录**: |
| 308 | + |
| 309 | +- **学习日志**:记录每天的学习内容和思考 |
| 310 | +- **问题解决记录**:记录遇到的问题和解决方案 |
| 311 | +- **协作记录**:记录团队协作中的贡献和收获 |
| 312 | + |
| 313 | +**阶段性反思**: |
| 314 | + |
| 315 | +- **周度反思**:每周进行学习反思和总结 |
| 316 | +- **项目里程碑反思**:在关键节点进行深度反思 |
| 317 | +- **同伴互评**:通过同伴评价了解自己的不足 |
| 318 | + |
| 319 | +### 成果性评估(Product Assessment) |
| 320 | + |
| 321 | +**项目成果质量**: |
| 322 | + |
| 323 | +- **功能完整性**:项目功能是否按计划完成 |
| 324 | +- **代码质量**:代码的可读性、可维护性、性能等 |
| 325 | +- **文档质量**:技术文档的完整性和准确性 |
| 326 | + |
| 327 | +**创新性评估**: |
| 328 | + |
| 329 | +- **技术方案创新**:是否提出了创新的技术方案 |
| 330 | +- **问题解决创新**:是否用创新的方式解决了问题 |
| 331 | +- **用户体验创新**:是否在用户体验方面有创新 |
| 332 | + |
| 333 | +### 能力性评估(Competency Assessment) |
| 334 | + |
| 335 | +**核心能力提升**: |
| 336 | + |
| 337 | +- **技术能力**:编程、架构、调试等技能提升 |
| 338 | +- **协作能力**:团队协作、沟通表达等能力提升 |
| 339 | +- **学习能力**:自主学习、问题解决等能力提升 |
| 340 | + |
| 341 | +**职业素养培养**: |
| 342 | + |
| 343 | +- **工程素养**:对代码质量、工程规范的重视程度 |
| 344 | +- **开源素养**:对开源文化的理解和参与程度 |
| 345 | +- **创新素养**:对新技术、新方法的探索精神 |
| 346 | + |
| 347 | +## 预期成果 |
| 348 | + |
| 349 | +通过 12 周的实训,学员将获得: |
| 350 | + |
| 351 | +1. **完整项目经验**:从 0 到 1 的完整项目交付经验 |
| 352 | +2. **技术能力提升**:扎实的工程实践能力和架构设计能力 |
| 353 | +3. **思维模式转变**:从执行者思维转向产品思维和架构思维 |
| 354 | +4. **个人品牌建设**:开源项目和技术博客作为个人技术名片 |
| 355 | +5. **职业发展机会**:优秀学员获得七牛云实习机会和推荐信 |
| 356 | +6. **持续学习能力**:具备持续学习、团队协作、迭代改进的学习能力 |
| 357 | + |
| 358 | +## 后续优化方向 |
| 359 | + |
| 360 | +1. **课程内容迭代**:根据学员反馈和行业变化持续优化 |
| 361 | +2. **导师团队扩充**:邀请更多行业专家加入导师团队 |
| 362 | +3. **项目类型丰富**:增加更多样化的项目类型和技术栈 |
| 363 | +4. **社区建设**:建立学员社区,促进长期交流与合作 |
| 364 | +5. **创客空间建设**:建立线上创客空间,支持学员持续创新 |
| 365 | +6. **产学研合作**:与高校、企业建立深度合作,提供更多实践机会 |
0 commit comments