-
Notifications
You must be signed in to change notification settings - Fork 8
add proposal for techcamp product #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
CarlJi
wants to merge
1
commit into
qiniu:main
Choose a base branch
from
CarlJi:proposal_product
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,365 @@ | ||||||
# 1024 实训营课程体系设计 | ||||||
|
||||||
## 设计理念 | ||||||
|
||||||
基于"成就优秀工程师"的愿景,1024 实训营采用"定方向-做架构-做实现"三大模块的课程体系,旨在培养具备产品思维、架构思维和工程实现能力的复合型工程师。在 AI 重构开发范式的时代背景下,我们更注重培养学员的元决策能力和系统思维,而非简单的代码编写技能。 | ||||||
|
||||||
**创客 PBL 模式融入**:我们借鉴创客空间(Maker Space)和项目式学习(Project-Based Learning)的理念,强调"做中学"、"协作共创"、"迭代改进"的学习模式,让学员在真实项目实践中获得成长。 | ||||||
|
||||||
## 课程体系概览 | ||||||
|
||||||
### 第一阶段:定方向(第 1-4 周) | ||||||
|
||||||
**目标:培养产品思维,学会定义问题和价值** | ||||||
|
||||||
#### 核心能力培养 | ||||||
|
||||||
- **需求分析能力**:学会从用户视角理解问题,识别真实需求 | ||||||
- **产品思维**:理解技术如何创造商业价值 | ||||||
- **价值定义能力**:学会评估技术方案的价值和优先级 | ||||||
|
||||||
#### 具体内容 | ||||||
|
||||||
1. **产品需求调研与分析** | ||||||
|
||||||
- 竞品分析方法 (一张表诉所有) | ||||||
- 功能对比矩阵:列出核心功能点,对比各竞品的实现情况 | ||||||
- 技术架构分析:研究竞品的技术选型和架构设计 | ||||||
- 用户体验分析:从用户角度体验竞品,记录优缺点 | ||||||
- 差异化定位:识别竞品的特色功能和市场定位 | ||||||
|
||||||
2. **产品设计思维** | ||||||
|
||||||
- 思维理念 (初级产品经理喜欢做加法,顶级产品经理做的是减法) | ||||||
- 做减法思维:从加法到减法的转变 | ||||||
- 精准定位:减到刚好精准命中用户心智 | ||||||
- 价值聚焦:识别核心价值,避免功能堆砌 | ||||||
- 用户思维 | ||||||
- 以用户为中心:从用户视角思考问题 | ||||||
- 用户旅程地图:理解用户使用产品的完整流程 | ||||||
- 同理心设计:站在用户角度感受痛点和需求 | ||||||
- 数据思维 | ||||||
- 数据驱动决策:基于数据而非直觉做产品决策 | ||||||
- 关键指标定义:识别产品的核心成功指标 | ||||||
- A/B 测试思维:通过实验验证产品假设 | ||||||
- 迭代思维 | ||||||
- 快速试错:小步快跑,快速验证 | ||||||
- 持续优化:基于反馈不断改进产品 | ||||||
- 版本规划:合理规划产品迭代节奏 | ||||||
|
||||||
#### 交付物 | ||||||
|
||||||
- **竞品分析文档**:包含功能对比矩阵、技术架构分析、用户体验分析、差异化定位等内容的完整竞品分析报告 | ||||||
- **产品需求文档(PRD)**:详细的产品需求描述,包含用户故事、功能规格、验收标准等 | ||||||
- **产品原型设计**:低保真或高保真的产品原型,用于验证产品概念和用户流程 | ||||||
- **技术可行性评估报告**:对技术方案的可行性、成本效益、风险评估的初步分析 | ||||||
|
||||||
--- | ||||||
|
||||||
### 第二阶段:做架构(第 5-8 周) | ||||||
|
||||||
**目标:培养架构思维,学会系统设计** | ||||||
|
||||||
#### 核心能力培养 | ||||||
|
||||||
- **系统思维**:理解复杂系统的整体性和关联性,学会从业务角度看待模块拆解 | ||||||
- **架构设计能力**:学会设计可扩展、可维护的系统架构,重点在于模块边界定义和资产设计 | ||||||
- **技术决策能力**:在多种技术方案中做出合理选择,基于价值=需求量 × 单价的商业思维 | ||||||
|
||||||
#### 具体内容 | ||||||
|
||||||
1. **架构设计基础** | ||||||
|
||||||
- **模块拆解思维**:学会将复杂系统拆解为独立的业务模块 | ||||||
|
||||||
- 每个模块都是独立的业务,有独立的需求边界和价值 | ||||||
- 模块边界设计:明确每个模块解决什么问题、不解决什么问题 | ||||||
- 资产设计:定义模块间的输入/输出资产,资产决定一切 | ||||||
- AI 辅助:使用 AI 工具分析系统复杂度,辅助模块拆解决策 | ||||||
|
||||||
- **连接与组合设计** | ||||||
- 实体边界问题:程序、动态库、包、模块、函数等实体的边界定义 | ||||||
- 模块间接口设计:如何连接和组合不同的模块 | ||||||
- 依赖关系管理:避免过度耦合,保持模块独立性 | ||||||
- AI 辅助:利用 AI 分析模块间依赖关系,识别潜在耦合问题 | ||||||
|
||||||
2. **技术方案评估** | ||||||
|
||||||
- **需求分析深度**:不是简单罗列需求,而是洞察需求的内在逻辑关联 | ||||||
|
||||||
- 需求发展方向预判:防止过度设计 | ||||||
- 需求逻辑关联分析:找到代价最低的实现路径 | ||||||
- 实体提炼:用实体来描述需求,建立需求间的关联 | ||||||
- AI 辅助:使用 AI 分析需求间的逻辑关联,辅助实体提炼 | ||||||
|
||||||
- **技术可行性分析**:评估技术方案的实现难度 | ||||||
- **成本效益分析**:开发成本 vs 预期收益 | ||||||
- **技术风险识别**:识别潜在的技术风险点 | ||||||
- **替代方案对比**:对比不同技术方案的优劣 | ||||||
- AI 辅助:利用 AI 进行多方案对比分析,生成技术选型建议 | ||||||
|
||||||
3. **性能与可扩展性设计** | ||||||
|
||||||
- 架构层面的性能考虑:理解性能瓶颈的常见位置 | ||||||
- 可扩展性设计原则:如何设计支持业务增长的架构 | ||||||
- 技术选型的性能影响:不同技术方案对性能的影响评估 | ||||||
- AI 辅助:使用 AI 进行性能瓶颈分析,优化架构设计 | ||||||
|
||||||
4. **架构落地实践** | ||||||
|
||||||
- **代码模块规格设计** | ||||||
|
||||||
- 模块接口定义:明确的输入输出规格 | ||||||
- 模块职责边界:每个模块的独立价值定位 | ||||||
- 模块间契约:模块如何协作的明确约定 | ||||||
- AI 辅助:利用 AI 生成模块接口规范,确保接口设计的一致性 | ||||||
|
||||||
- **模块串联实现** | ||||||
|
||||||
- 连接性代码编写:实现模块间的连接逻辑 | ||||||
- 资产流转设计:确保资产在模块间稳定传递 | ||||||
- 错误处理机制:模块间异常情况的处理策略 | ||||||
- AI 辅助:使用 AI 生成连接性代码模板,提高开发效率 | ||||||
|
||||||
- **架构演进管理** | ||||||
- 模块重构策略:如何在不破坏整体架构的前提下优化模块 | ||||||
- 向后兼容性:确保架构演进不影响现有功能 | ||||||
- 性能优化:在架构层面进行性能调优 | ||||||
- AI 辅助:利用 AI 分析架构演进影响,生成重构建议 | ||||||
|
||||||
#### 交付物 | ||||||
|
||||||
- **系统架构设计文档**:详细的系统架构设计,包含架构图、模块划分、接口定义等 | ||||||
- **模块规格说明书**:每个模块的详细规格定义,包含接口、职责、边界等 | ||||||
- **模块串联设计文档**:模块间如何连接和组合的详细设计 | ||||||
- **技术选型报告**:技术栈选型的详细分析和决策过程 | ||||||
- **技术方案评估报告**:多方案对比分析,包含可行性、成本效益、风险评估 | ||||||
- **架构评审记录**:团队架构评审的讨论记录和决策过程 | ||||||
- **代码实现验证**:通过实际代码实现验证架构设计的可行性 | ||||||
|
||||||
--- | ||||||
|
||||||
### 第三阶段:做实现(第 9-12 周) | ||||||
|
||||||
**目标:培养设计驱动开发能力,学会高质量交付** | ||||||
|
||||||
#### 核心能力培养 | ||||||
|
||||||
- **设计驱动能力**:学会通过精确的设计指导 AI 生成高质量代码 | ||||||
- **代码规范意识**:追求极致的代码质量和工程规范 | ||||||
- **AI 协作能力**:学会与 AI 高效协作,提升开发效率 | ||||||
|
||||||
#### 具体内容 | ||||||
|
||||||
1. **设计驱动开发实践** | ||||||
|
||||||
- **精确设计规范** | ||||||
|
||||||
- 接口设计规范:如何设计清晰、一致的 API 接口 | ||||||
- 数据结构设计:如何设计高效、可扩展的数据结构 | ||||||
- 算法设计规范:如何设计正确、高效的算法 | ||||||
- AI 辅助:使用 AI 验证设计方案的合理性和完整性 | ||||||
|
||||||
- **AI 代码生成与优化** | ||||||
- 设计到代码的转换:如何将设计规范转化为 AI 指令 | ||||||
- 代码生成策略:分模块、分层次的代码生成方法 | ||||||
- 代码质量检查:确保 AI 生成代码符合工程规范 | ||||||
- AI 辅助:利用 AI 进行代码质量分析和优化建议 | ||||||
|
||||||
2. **工程规范与最佳实践** | ||||||
|
||||||
- **代码规范与风格指南** | ||||||
|
||||||
- 命名规范:变量、函数、类的命名规则 | ||||||
- 代码结构规范:模块组织、文件结构的最佳实践 | ||||||
- 注释规范:如何编写清晰、有用的代码注释 | ||||||
- AI 辅助:使用 AI 工具自动检查和修复代码规范问题 | ||||||
|
||||||
- **版本控制与协作流程** | ||||||
- Git 工作流程:分支管理、提交规范 | ||||||
- Code Review 流程:设计评审、代码评审的标准流程 | ||||||
- 协作规范:团队协作中的沟通和决策机制 | ||||||
- AI 辅助:利用 AI 辅助代码评审,提高评审效率 | ||||||
|
||||||
3. **质量保障体系** | ||||||
|
||||||
- **测试策略设计** | ||||||
|
||||||
- 测试用例设计:如何设计全面、有效的测试用例 | ||||||
- 测试覆盖策略:单元测试、集成测试、端到端测试的平衡 | ||||||
- 自动化测试:如何设计可维护的自动化测试 | ||||||
- AI 辅助:使用 AI 生成测试用例,提高测试覆盖率 | ||||||
|
||||||
- **代码质量监控** | ||||||
- 静态代码分析:使用工具进行代码质量检查 | ||||||
- 性能监控:关键性能指标的监控和分析 | ||||||
- 安全审查:代码安全漏洞的识别和修复 | ||||||
- AI 辅助:利用 AI 进行代码质量评估和安全分析 | ||||||
|
||||||
#### 交付物 | ||||||
|
||||||
- **设计规范文档**:详细的设计规范和标准,包含接口设计、数据结构设计等 | ||||||
- **AI 协作指南**:与 AI 协作的最佳实践和工具使用指南 | ||||||
- **完整的项目代码库**:包含所有源代码、配置文件、测试代码的完整项目 | ||||||
- **代码质量报告**:详细的代码质量评估和优化建议 | ||||||
- **测试策略文档**:测试用例设计、测试覆盖策略的详细文档 | ||||||
- **项目总结报告**:项目开发过程的总结和经验分享 | ||||||
- **个人成长记录**:个人在项目中的成长轨迹和技能提升记录 | ||||||
|
||||||
## 实训营特色模式 | ||||||
|
||||||
### 1. 真实项目实践(Real Project Practice) | ||||||
|
||||||
**真实项目场景**:每个学员都参与真实的开源项目开发,而非模拟练习, 如: | ||||||
|
||||||
- **XGo 编译器项目**:参与编程语言底层技术开发 | ||||||
- **Go+ Builder 项目**:构建可视化编程教育平台 | ||||||
|
||||||
**问题导向**:从真实的技术问题出发,激发学习动机, 如: | ||||||
|
||||||
- 如何基于 AI 构建智能运维能力 | ||||||
- 如何降低 Go+ Builder 的使用门槛? | ||||||
- 如何优化 XGo 编译器的类型推导机制? | ||||||
|
||||||
### 2. 团队协作学习(Team Collaboration Learning) | ||||||
|
||||||
**跨角色协作**:不同技术背景的学员组成团队(前端、后端、算法等) | ||||||
|
||||||
**知识共享机制**: | ||||||
|
||||||
- **技术分享会**:每周进行技术分享? | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [nitpick] Replace the half-width question mark with a full-width one ('?') or remove it if not intended as a question.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
- **代码评审会**:定期进行代码评审和最佳实践讨论 | ||||||
- **问题解决工作坊**:针对共性问题进行集体攻关 | ||||||
|
||||||
### 3. 迭代改进学习(Iterative Learning) | ||||||
|
||||||
**快速原型**:鼓励学员快速构建原型,验证想法 | ||||||
|
||||||
**持续反馈**: | ||||||
|
||||||
- **导师反馈**:定期获得导师的技术指导和建议 | ||||||
- **同伴反馈**:通过代码评审获得同伴的建议 | ||||||
- **用户反馈**:通过实际使用获得真实用户反馈 | ||||||
|
||||||
### 4. 开源社区融入(Open Source Integration) | ||||||
|
||||||
**过程开源**:所有项目代码都开源到 GitHub | ||||||
|
||||||
- 阶段性成果在技术社区分享 | ||||||
- 经验总结与技术博客输出 | ||||||
- 开源贡献作为个人技术名片 | ||||||
- 持续维护:毕业后继续参与项目维护和迭代 | ||||||
|
||||||
**技术博客输出**: | ||||||
|
||||||
- 经验总结:将学习过程中的经验总结为技术博客 | ||||||
- 知识分享:通过技术分享帮助更多人学习 | ||||||
- 个人品牌:建立个人技术品牌和影响力 | ||||||
|
||||||
### 5. 行业大咖指导(Industry Expert Guidance) | ||||||
|
||||||
**导师规范**: | ||||||
|
||||||
- 任务以书面形式明确给出 | ||||||
- 讨论内容沉淀为文档 | ||||||
- 定期技术分享与经验交流 | ||||||
- 个性化成长指导 | ||||||
|
||||||
**行业大咖分享**: | ||||||
|
||||||
- 邀请技术大咖进行专题讲座 | ||||||
- 直播分享与互动交流 | ||||||
- 短视频内容制作与分发 | ||||||
- 导师经验分享与技术答疑 | ||||||
|
||||||
## 工程习惯培养 | ||||||
|
||||||
### 基于 PR 的开发协作流程 | ||||||
|
||||||
推荐采用基于 PR(Pull Request)的开发协作流程,每个 PR 都应该包含: | ||||||
|
||||||
- **问题背景**:为什么要做这个改动 | ||||||
- **参考依据**:基于什么考虑做出这个决策 | ||||||
- **方案对比**:考虑了哪些方案,各自的优劣 | ||||||
- **最终决策**:为什么选择当前方案 | ||||||
- **预期效果**:期望达到什么样的效果 | ||||||
|
||||||
### Code Review Comments 沉淀机制 | ||||||
|
||||||
为了形成有实训营风格的写代码规范,我们建立以下机制: | ||||||
|
||||||
- **Issue 记录 PR Comments**:每个 PR 的 review comments 都要记录在对应的 Issue 中 | ||||||
- **决策过程文档化**:将 review 过程中的讨论、决策、权衡都沉淀为文档 | ||||||
- **最佳实践总结**:定期总结 review 中发现的共性问题,形成最佳实践指南 | ||||||
- **规范迭代优化**:基于 review 反馈持续优化代码规范和开发流程 | ||||||
|
||||||
### 代码规范要求 | ||||||
|
||||||
- 严格的代码风格检查 | ||||||
- 完整的单元测试覆盖 | ||||||
- 详细的代码注释和文档 | ||||||
- 定期的代码质量评估 | ||||||
|
||||||
## 实训营评估体系 | ||||||
|
||||||
### 过程性评估(Process Assessment) | ||||||
|
||||||
**学习过程记录**: | ||||||
|
||||||
- **学习日志**:记录每天的学习内容和思考 | ||||||
- **问题解决记录**:记录遇到的问题和解决方案 | ||||||
- **协作记录**:记录团队协作中的贡献和收获 | ||||||
|
||||||
**阶段性反思**: | ||||||
|
||||||
- **周度反思**:每周进行学习反思和总结 | ||||||
- **项目里程碑反思**:在关键节点进行深度反思 | ||||||
- **同伴互评**:通过同伴评价了解自己的不足 | ||||||
|
||||||
### 成果性评估(Product Assessment) | ||||||
|
||||||
**项目成果质量**: | ||||||
|
||||||
- **功能完整性**:项目功能是否按计划完成 | ||||||
- **代码质量**:代码的可读性、可维护性、性能等 | ||||||
- **文档质量**:技术文档的完整性和准确性 | ||||||
|
||||||
**创新性评估**: | ||||||
|
||||||
- **技术方案创新**:是否提出了创新的技术方案 | ||||||
- **问题解决创新**:是否用创新的方式解决了问题 | ||||||
- **用户体验创新**:是否在用户体验方面有创新 | ||||||
|
||||||
### 能力性评估(Competency Assessment) | ||||||
|
||||||
**核心能力提升**: | ||||||
|
||||||
- **技术能力**:编程、架构、调试等技能提升 | ||||||
- **协作能力**:团队协作、沟通表达等能力提升 | ||||||
- **学习能力**:自主学习、问题解决等能力提升 | ||||||
|
||||||
**职业素养培养**: | ||||||
|
||||||
- **工程素养**:对代码质量、工程规范的重视程度 | ||||||
- **开源素养**:对开源文化的理解和参与程度 | ||||||
- **创新素养**:对新技术、新方法的探索精神 | ||||||
|
||||||
## 预期成果 | ||||||
|
||||||
通过 12 周的实训,学员将获得: | ||||||
|
||||||
1. **完整项目经验**:从 0 到 1 的完整项目交付经验 | ||||||
2. **技术能力提升**:扎实的工程实践能力和架构设计能力 | ||||||
3. **思维模式转变**:从执行者思维转向产品思维和架构思维 | ||||||
4. **个人品牌建设**:开源项目和技术博客作为个人技术名片 | ||||||
5. **职业发展机会**:优秀学员获得七牛云实习机会和推荐信 | ||||||
6. **持续学习能力**:具备持续学习、团队协作、迭代改进的学习能力 | ||||||
|
||||||
## 后续优化方向 | ||||||
|
||||||
1. **课程内容迭代**:根据学员反馈和行业变化持续优化 | ||||||
2. **导师团队扩充**:邀请更多行业专家加入导师团队 | ||||||
3. **项目类型丰富**:增加更多样化的项目类型和技术栈 | ||||||
4. **社区建设**:建立学员社区,促进长期交流与合作 | ||||||
5. **创客空间建设**:建立线上创客空间,支持学员持续创新 | ||||||
6. **产学研合作**:与高校、企业建立深度合作,提供更多实践机会 |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] Nested bullet points under a numbered heading may be clearer if converted to a numbered sublist to maintain consistent structure.
Copilot uses AI. Check for mistakes.