DEV Community: Tuo Cheng

底层服务 vs 高层服务：开发协作的典型特点

Tuo Cheng — Wed, 14 Jan 2026 09:29:51 +0000

底层服务

稳定性优先：需求不是“多”，而是“任何变更都可能放大事故面”，所以更强调回归、灰度、可观测、降级与补偿。
接口契约极强：对外接口（RPC/HTTP/MQ 消息）要长期兼容，字段更倾向“只加不改/不删”，版本管理更严。
协作方式偏“被动 + SLA”：别人来依赖你，你需要给的是清晰边界、SLA、错误码语义、排障手册；不然一出问题所有人都来问你。
变更节奏更慢：倾向小步快跑但“可控”，一切变更都要可回滚；对“临时方案/热修”容忍度低。
问题形态更工程化：大多是幂等、乱序、重试、容量、外部依赖抖动、数据一致性、任务堆积这类系统性问题。
对齐成本在“上下游联动”：你改一点，上游要跟着改或跟着适配，所以需要提前公告、给测试环境、给兼容期。
成就感来自“没人找你”：真正做稳了，日常是安静的；出事时才会被看见。

高层服务（经常被提需求，和多方协作，比如业务编排/产品侧系统）

需求驱动优先：核心矛盾是“快”和“不断变”，更强调交付速度、业务正确性、可配置、可运营。
接口变化更频繁：对接对象多（产品、运营、风控、客服、外部合作方），字段/流程经常改，版本迭代更快。
协作方式偏“主动对齐 + 驱动”：你要拉齐口径、推进决策、拆解需求、协调排期，很多时间花在沟通和确认。
变更节奏更快：允许短周期迭代，先跑通再优化；但需要通过 feature flag、AB、配置化来控制风险。
问题形态更业务化：规则遗漏、边界条件、权限/风控、对账口径、流程分支、数据展示一致性等。
依赖管理更复杂：你依赖很多底层能力，底层抖动会直接拖慢你交付，所以更需要缓存/降级/兜底策略来“对冲依赖不稳定”。
成就感来自“用户/业务指标”：上线效果、转化、成本、时效这些更直接。

一句话总结（协作心法）

底层服务：把“不确定性”封装掉，对外提供稳定契约与可预期的失败方式（可重试/可补偿），协作靠规则和标准化。
高层服务：把“变化”吸收掉，快速对齐多方诉求并交付可运营的业务能力，协作靠推动与取舍。

软件行业的未来十年大变局：当AI重构整个生态

Tuo Cheng — Fri, 05 Sep 2025 02:52:56 +0000

引言：一个让人深思的问题

最近在一个技术论坛上，看到一个让人深思的讨论：

"如果AI让软件开发的门槛大幅降低，新人用1-3年就能掌握传统需要5-10年才能学会的技术，那么：

软件行业的薪资会不会大幅下降？

这个行业会不会越来越年轻化？

AI越来越强，从业者会不会越来越少？

最终会不会完全由AI接管软件开发？"

这些问题触及了每个软件从业者内心深处的焦虑。作为一个在技术行业观察多年的从业者，我想和大家分享一下对未来10年软件行业变化的思考和预测。

第一波冲击：技能门槛的快速下沉（2024-2027）

现象：3年新人 = 10年老手？

这个趋势已经在发生：

传统学习周期 vs AI辅助学习:
  前端开发: 2-3年 → 3-6个月
  后端架构: 3-5年 → 6-12个月  
  系统设计: 5-8年 → 1-2年
  技术选型: 5-10年经验积累 → AI瞬间给出对比分析

我最近接触了几个刚毕业的开发者，他们通过AI辅助开发，在短短几个月内就能设计出相当复杂的系统架构，代码质量也不错。这在以前是不可想象的。

直接影响：初级岗位的"内卷"加剧

供给端变化：

新人上手更快，培训成本降低
传统"科班出身"的优势被稀释
跨专业转行的门槛大幅降低
更多人涌入软件行业

需求端变化：

企业对"初级开发"的需求可能减少
更需要能够高效利用AI的"AI协作型开发者"
对业务理解能力的要求大幅提升

预测结果：
🔴 初级岗位（0-3年）薪资可能出现下降趋势

供给大量增加，竞争加剧
门槛降低导致替代性增强
预计薪资下降15-30%

🟡 中级岗位（3-8年）出现分化

AI协作能力强的：薪资持平或微增
传统技能导向的：薪资下降10-20%

🟢 高级岗位（8年以上）薪资可能上升

真正的架构设计和业务洞察更稀缺
AI无法替代的创新能力更加珍贵

第二波重构：职业角色的深度分化（2027-2030）

新的职业生态出现

传统的"程序员"职业将分化为几个不同方向：

1. AI驱动工程师（AI-Driven Engineer）

核心能力:
  - 精通各种AI开发工具
  - 高效的AI协作技巧
  - 快速学习和适应新技术
  - 业务需求到技术实现的快速转换

市场需求: 📈 大幅增长
薪资趋势: 💰 中等偏上
年龄结构: 👶 以年轻人为主（25-35岁）

2. 业务架构师（Business Architect）

核心能力:
  - 深度的业务领域知识
  - 复杂问题的抽象和建模
  - 技术方案的权衡和决策
  - 跨部门的沟通协调

市场需求: 📈 稳步增长
薪资趋势: 💰💰 高薪（但需要长期积累）
年龄结构: 🧑‍💼 中年为主（30-45岁）

3. AI产品专家（AI Product Specialist）

核心能力:
  - 理解AI能力的边界和应用场景
  - 设计AI原生的产品功能
  - AI系统的性能调优和监控
  - AI伦理和安全考虑

市场需求: 📈📈 爆发式增长
薪资趋势: 💰💰💰 高薪（新兴稀缺岗位）
年龄结构: 🎯 各年龄段都有机会

4. 系统创新者（System Innovator）

核心能力:
  - 前沿技术的敏感度和判断力
  - 跨领域知识的整合创新
  - 技术趋势预测和方向把控
  - 复杂系统的原创性设计

市场需求: 📈 小众但高价值
薪资趋势: 💰💰💰💰 顶级薪资
年龄结构: 🌟 通常需要丰富经验（35岁以上）

年龄结构的变化趋势

2024-2027年：年轻化趋势明显

新人AI协作能力强，上手快
传统经验优势被快速稀释
35岁以上程序员面临转型压力

2027-2030年：重新平衡

年轻人在AI协作方面的优势
中年人在业务理解和判断力方面的优势
形成不同岗位的年龄适配

第三波变革：AI能力的指数级增长（2030-2034）

AI开发能力的演进预测

2025年：AI助手时代

AI帮助写代码、设计架构
人类仍然主导开发流程
开发效率提升3-5倍

2028年：AI协作时代

AI能够理解复杂业务需求
人机协作更加深入和自然
开发效率提升10-20倍

2032年：AI主导时代？

AI能够独立完成大部分开发任务
人类角色转向监督、验证、创新
软件开发从业者数量可能大幅减少

从业者数量的变化预测

阶段性变化：

2024-2026年: 📈 数量增长期
  - AI降低门槛，更多人进入行业
  - 数字化需求持续增长
  - 从业者总数可能增长20-30%

2027-2029年: 📊 结构调整期  
  - 初级岗位需求下降
  - 高级岗位需求上升
  - 总数基本持平，但结构大调整

2030-2034年: 📉 数量收缩期
  - AI能力大幅提升
  - 部分岗位被AI替代
  - 从业者总数可能下降30-50%

2035年以后: ❓ 新平衡期
  - 形成新的人机协作模式
  - 人类专注于AI无法胜任的工作
  - 行业重新稳定，但规模更小、价值更高

薪资结构的重新洗牌

未来薪资分化预测

金字塔结构将更加陡峭：

顶层（5%的从业者）:
  职位: 系统创新者、AI产品专家、首席架构师
  薪资: 💰💰💰💰 100万-500万+
  特征: 不可替代的创新能力和判断力

中上层（15%的从业者）:
  职位: 业务架构师、资深AI工程师、技术领域专家
  薪资: 💰💰💰 50万-150万
  特征: 深度专业能力 + AI协作能力

中层（30%的从业者）:
  职位: AI驱动工程师、产品技术经理
  薪资: 💰💰 25万-60万  
  特征: 高效的AI协作能力 + 一定业务理解

底层（50%的从业者）:
  职位: 可能被AI替代或转向其他行业
  薪资: 💰 15万-30万（如果还在行业内）
  特征: 传统编程技能，AI协作能力不足

薪资变化的根本逻辑

价值创造能力重新定义：

创造性工作的价值大幅上升
重复性工作的价值快速下降
人机协作效率成为薪资的关键决定因素
业务价值转化能力比纯技术能力更重要

行业生态的深度重构

公司组织结构的变化

技术团队规模缩小，但价值密度提升：

传统团队（2024年）:
  - 前端开发 × 5
  - 后端开发 × 8  
  - 测试工程师 × 3
  - 运维工程师 × 2
  - 架构师 × 1
  总计: 19人

AI时代团队（2030年）:
  - AI协作工程师 × 3
  - 业务架构师 × 1
  - AI产品专家 × 1
  - 系统创新者 × 1
  总计: 6人，但产出可能是传统团队的2-3倍

新的商业模式涌现

AI Native公司的特征：

极小的技术团队，极高的产出效率
快速迭代和试错能力
个人或小团队创业的门槛大幅降低
"一人公司"或"三人公司"可能做出影响力巨大的产品

应对策略：在变局中找到自己的位置

给不同阶段从业者的建议

新人（0-3年）：拥抱AI，建立差异化

❌ 避免的陷阱：

只学传统编程技能
忽视业务理解能力
过度依赖AI，失去基础思考能力

✅ 正确的策略：

核心能力建设:
  1. 精通AI协作工具和方法
  2. 快速学习新技术的能力
  3. 选择一个业务领域深入理解
  4. 培养产品思维和用户视角

职业规划:
  - 目标：成为AI驱动工程师或AI产品专家
  - 时间：2-3年建立基础竞争力
  - 策略：技术广度 + 业务深度 + AI协作效率

中级开发者（3-8年）：转型窗口期

❌ 危险信号：

仍然抗拒AI工具
只专注技术细节，忽视业务价值
没有建立独特的专业优势

✅ 转型方向：

选择1: 业务架构师
  - 深挖某个行业的业务知识
  - 提升系统设计和权衡能力
  - 加强跨部门沟通协调技能

选择2: AI产品专家  
  - 深度学习AI技术原理和应用
  - 了解AI的能力边界和最佳实践
  - 建立AI系统的设计和优化能力

选择3: 技术管理者
  - 发展团队管理和人员培养能力
  - 学习业务战略和产品规划
  - 建立技术决策和资源配置能力

资深开发者（8年以上）：守住高地

✅ 核心优势：

经验优势:
  - 对技术趋势的判断力
  - 复杂问题的分解和解决经验
  - 业务理解的深度和广度
  - 技术决策的权衡能力

发展方向:
  - 系统创新者：引领技术方向
  - 首席架构师：设计复杂系统
  - 技术专家：成为某领域的权威
  - 创业者：利用AI创业的机会

给企业的建议

人才策略调整：

招聘重点:
  ❌ 不再只看技术技能熟练度
  ✅ 重点评估AI协作能力
  ✅ 重点评估学习适应能力
  ✅ 重点评估业务理解能力
  ✅ 重点评估创新思维能力

组织架构:
  - 扁平化管理，减少层级
  - 小团队，高效率
  - 项目制，灵活调配
  - 鼓励内部创业和创新

文化建设:
  - 拥抱变化，持续学习
  - 鼓励试验，容忍失败  
  - 重视创新，奖励突破
  - 人机协作，和谐发展

长远展望：软件行业的终局会是什么？

情景一：AI完全接管？（概率：20%）

特征：

2035年后，AI能够独立完成99%的软件开发工作
人类软件开发者基本消失
只需要极少数AI系统的维护者和监督者

影响：

软件成本接近于零
创新速度极大加速
大量程序员转行到其他领域

情景二：人机深度协作（概率：60%）

特征：

AI负责具体实现，人类负责创意和决策
形成稳定的人机协作模式
软件开发者数量大幅减少，但价值大幅提升

影响：

行业从业者减少70-80%
剩余从业者薪资大幅提升
软件创新能力达到前所未有的高度

情景三：新的平衡点（概率：20%）

特征：

AI发展遇到瓶颈，无法完全替代人类
人类在创造性和判断性工作上保持优势
形成新的分工和协作关系

影响：

行业规模缩小但保持稳定
对从业者的能力要求大幅提升
技术创新速度放缓但更加务实

写在最后：变化中的机遇与挑战

面对这样的大变局，每个软件从业者都应该问自己几个问题：

我的核心价值是什么？ 是AI难以替代的创造力，还是可以被快速复制的技能？
我在为未来做准备吗？ 是在拥抱变化学习新技能，还是在固守传统抗拒改变？
我如何在变化中找到机会？ 是被动等待行业洗牌，还是主动寻找新的价值创造点？

我的观点是：

🌟 这是软件行业历史上最大的变革，也是最大的机遇

传统的竞争规则被打破，新的机会涌现
AI降低了创业和创新的门槛
个人价值创造的可能性被极大放大

🚀 适应变化的人将获得前所未有的机会

能够驾驭AI的开发者将拥有超人般的生产力
深度理解业务的技术专家将变得更加稀缺和珍贵
跨领域创新者将开辟全新的商业空间

⚡ 变化的速度比我们想象的更快

不要等到明天才开始准备
不要低估AI发展的速度
不要高估传统技能的持久价值

最后的建议：
拥抱变化，保持学习，找到自己在AI时代的独特价值。软件行业的未来10年将是动荡的10年，也将是机遇无限的10年。关键是要站在变化的前面，而不是被变化推着走。

你准备好迎接这个变局了吗？

AI 时代的技术能力大洗牌：当架构师门槛被大幅降低

Tuo Cheng — Fri, 05 Sep 2025 02:45:32 +0000

引言：一个让人不安的发现

最近在和几位技术朋友聊天时，一个年轻的开发者小王向我吐露了一个困惑：

"我们团队有个技术专家，在大厂干了十多年，对业务理解很深。但最近我发现，通过AI的帮助，我似乎也能做到他能做的大部分工作。架构设计？问问AI，学几天就懂了。复杂开发？AI协助下更不是问题。这种感觉很奇怪，是我的错觉吗？"

小王的困惑让我深思。作为一个在技术行业摸爬滚打多年的从业者，我意识到他触及了一个正在发生但尚未被充分讨论的现象：AI正在重新洗牌整个技术能力的价值体系。

AI确实在"拉平"传统技能差距

传统架构师的护城河正在消失

让我们先承认一个不舒服但真实的事实：AI确实在大幅降低传统技术门槛。

以前需要5-10年才能积累的架构能力，现在可能几天就能掌握：

系统设计模式:
  传统学习路径: 读书 → 项目实践 → 试错优化 (2-3年)
  AI辅助路径: 与AI对话 → 快速理解 → 实例验证 (2-3天)

技术选型决策:
  传统决策依据: 有限的个人经验 + 网络调研 (数周)
  AI协助决策: 全面的方案对比 + 最佳实践 (数小时)

最佳实践积累:
  传统积累方式: 踩坑 → 复盘 → 总结 (数年)
  AI直接获取: 行业成熟经验 + 即时应用 (立即)

我认识的一个资深架构师老张最近也承认："现在的年轻人用AI，确实能很快掌握我花了很多年才学会的东西。"

为什么会出现这种现象？

AI本质上是一个"经验放大器"：

它相当于一个随时在线的资深顾问
能够瞬间调用全球最佳实践案例
没有个人偏见和知识盲区
能够快速生成和验证各种方案

传统架构师的核心优势正在被快速复制：

设计模式知识 → AI都知道，还能给出多种变体
技术选型经验 → AI能快速分析各方案优劣
最佳实践积累 → AI直接提供成熟的行业方案
常见问题解决 → AI的"见识"比任何个人都广

但能力层次的差异依然存在

虽然AI大幅降低了入门门槛，但技术能力仍然存在明显的层次差异。让我们重新审视这个金字塔：

Level 1: 基础架构设计 (AI已大幅拉平)

典型能力：

常见设计模式的应用
标准技术栈的选型
基础的高可用设计
常规的性能优化方案

AI的影响： 🔴 几乎完全拉平了差距

一个新人通过AI协助设计电商系统架构，和有5年经验的架构师设计出来的方案可能差别不大。这个层次的价值正在快速贬值。

Level 2: 复杂业务架构 (仍有显著差异)

典型能力：

深度理解特定领域的业务复杂性
在多重约束条件下的权衡和取舍
业务增长带来的架构演进规划
跨系统的数据一致性设计

AI的影响： 🟡 部分降低门槛，但差异依然明显

关键差异在于业务理解深度。 比如：

一个经验丰富的金融系统架构师知道哪些"最佳实践"在金融场景下不适用
他了解监管要求的细节变化，知道合规的边界在哪里
他能预判业务发展对架构的长远影响
他知道这个行业特有的"坑"都在什么地方

AI可以提供通用的架构方案，但这种深度的业务洞察仍然需要时间和实践积累。

Level 3: 创新性架构 (AI难以替代)

典型能力：

创造性地解决前所未有的问题
预判技术趋势和架构演进方向
在高度不确定性中做出关键决策
平衡技术债务和业务发展速度

AI的影响： 🟢 基本无法替代

这个层次需要的是直觉、判断力和创新思维：

什么时候该重构，什么时候该重写？
如何在快速发展和系统稳定性之间平衡？
新技术什么时候值得冒险引入？
如何设计出真正突破性的技术方案？

这些问题没有标准答案，需要的是深度的洞察力和创新能力。

Level 4: 组织架构 (完全无法替代)

典型能力：

技术团队的组织和管理
跨部门的协调和推动能力
技术文化的建立和传承
人才的识别、培养和激励

这个层次完全依赖于人的软技能，AI目前还无法涉足。

AI时代的新价值体系

传统的技术能力金字塔正在被重构。新的价值体系不再是简单的垂直等级，而是多维度的能力组合：

维度1: AI协作效率 (新的核心竞争力)

AI原生开发者 vs 传统开发者

能够高效利用AI完成复杂任务 vs 抗拒或不熟练AI协作
快速学习和应用新技术 vs 依赖传统的慢速开发模式
开发效率是传统方式的3-5倍 vs 效率提升有限

我见过一个刚毕业的开发者，通过AI协助在一周内完成了一个复杂的微服务架构设计和实现，质量不亚于资深工程师的作品。这种效率差异正在成为新的核心竞争力。

维度2: 业务洞察深度 (依然重要)

业务专家型技术人 vs 纯技术型选手

深度理解特定领域的业务复杂性 vs 只懂技术实现
能预判业务发展趋势 vs 被动响应需求
知道行业的"隐藏规则" vs 容易踩业务逻辑的坑

但值得注意的是，AI也在加速业务知识的获取。一个聪明的开发者可以通过AI快速学习领域知识，缩短这个差距。

维度3: 创新整合能力 (最高价值)

跨领域创新者 vs 单领域专家

结合多个领域创造新价值 vs 只精通单一领域
发现传统专家看不到的机会 vs 创新潜力有限
用新技术解决传统问题 vs 思维固化

这是AI时代最稀缺的能力。能够将AI、区块链、IoT等新技术与传统业务深度结合的人，将成为最有价值的技术人才。

给技术人的建议：如何在新时代建立优势

拥抱变化，而不是抗拒

如果你还在纠结"AI是否会取代程序员"，那你已经落后了。真正的问题是："如何成为最会利用AI的程序员？"

短期策略（3-6个月）：

成为团队的AI效率专家
建立AI协作的方法论和最佳实践
用实际成果证明AI协作的价值

中期策略（6-18个月）：

深化特定领域的业务理解
建立技术+业务的复合能力
成为"懂业务的技术专家"或"懂技术的业务专家"

长期策略（1-3年）：

建立跨领域的创新整合能力
在技术社区建立思想领导力
成为新技术趋势的引领者

重新定义学习方法

传统的"深度学习单一技术栈"的方法已经过时。新的学习策略应该是：

概念优先学习法：

快速理解核心概念和设计理念（30分钟）
用AI生成实现示例（10分钟）
分析AI实现的优缺点（20分钟）
针对具体场景优化改进（30分钟）

问题驱动学习法：

从实际问题出发："如何设计一个高并发系统？"
而不是："学习Redis使用方法"

AI辅助深度学习法：

让AI成为你的学习助手和对话伙伴
通过提问和讨论加深理解
用AI生成的代码来验证概念理解

建立差异化的个人品牌

在AI快速拉平技术差距的时代，个人品牌变得更加重要：

技术+业务的复合能力：
选择一个你感兴趣的业务领域深耕，成为既懂技术又懂业务的复合型人才。

AI协作的最佳实践：
总结和分享你的AI协作经验，成为这个新兴领域的专家。

跨领域的创新思维：
关注多个技术领域的发展，寻找跨领域结合的创新机会。

写在最后：焦虑还是兴奋？

回到文章开头小王的困惑。是的，AI确实在快速拉平传统的技术能力差距。但这不应该让我们焦虑，而应该让我们兴奋！

为什么？

门槛降低意味着更多机会：你可以更快地进入以前需要多年积累才能触及的领域
效率提升释放创造力：不用再把时间花在重复性工作上，可以专注于真正有价值的创新
竞争维度发生了变化：不再比谁记得住更多语法，而是比谁能更好地解决实际问题
新的价值创造空间正在打开：AI+各行业的结合还有无限可能

最重要的观念转变是：
不要试图在传统赛道上追赶传统专家，而要在新赛道上建立自己的领先优势。

AI时代的赢家不是最懂传统技术的人，而是最会利用AI创造价值的人。

你准备好成为AI时代的技术专家了吗？

如果你对AI时代的技术发展有自己的见解，欢迎在评论区分享交流。让我们一起探索这个充满变化和机遇的新时代。

相关阅读推荐：

《AI如何改变软件开发》
《重新定义程序员的核心价值》
《从编程到产品：技术人的转型之路》

标签： #AI开发 #技术成长 #架构师 #职业发展 #程序员转型

AI 编程时代的焦虑：我是不是没学到东西？

Tuo Cheng — Fri, 05 Sep 2025 02:37:14 +0000

在当下大量使用 AI 编程的公司里，很多工程师都会产生一种相似的焦虑：
“我原本想通过项目学习 Go 的语法和编程，但因为过度依赖 AI，我的 Go 能力似乎没有进步。”

这种担忧非常真实，也非常普遍。本文将从理解焦虑的根源开始，帮助您重新定义学习标准，并提供一套可操作的成长路径。

一、理解您的焦虑：这是 AI 时代的普遍困惑

1. 您的焦虑完全可以理解 😟

很多工程师在使用 AI 编程后会产生错觉：

“我 Go 语法还不熟练” ❌
“不能脱离 AI 独立编程” ❌
“感觉像在‘作弊’” ❌
“担心面试时无法手写代码” ❌

但实际上，您可能已经获得了另一类更有价值的能力：

✅ 设计复杂系统架构
✅ 掌握并发与分布式原理
✅ 快速理解和应用新技术
✅ 高效协作 AI 完成开发任务

焦虑的根源在于：仍然用传统的“语法熟练度”来衡量现代开发能力，低估了自己在系统思维和业务建模上的成长。

二、重新定义“学会了”的标准

传统标准（已过时）

❌ 能背诵 Go 语法规则
❌ 不看文档写出完整程序
❌ 熟记标准库函数
❌ 手写复杂数据结构
❌ 脱离搜索引擎编程

AI 时代的新标准

✅ 理解 Go 的设计理念（并发、内存管理）
✅ 能设计 Go 微服务的架构
✅ 知道何时选择 Go 而非其他语言
✅ 能与 AI 协作高效开发
✅ 能阅读和优化 AI 生成的 Go 代码
✅ 理解 Go 在分布式系统中的价值

换句话说：您已经在学习，但学到的是更高层次的能力。

三、平衡 AI 使用与深度学习的方法 ⚖️

1. 80/20 原则

20% 时间：脱离 AI，深度学习核心原理
- goroutine vs thread
- channel 底层实现
- defer 执行时机
- slice/map 内存结构
- 错误处理机制
80% 时间：借助 AI 高效完成架构与业务开发
- 设计高并发服务
- 优化代码性能
- 架构建模和测试

2. 验证学习效果的新方法

传统验证（已过时）

能否不查资料写语法？
能否记住所有标准库函数？

现代验证（更有意义）

能否设计处理 10 万 QPS 的服务架构？
能否识别并优化 AI 生成代码的潜在问题？
能否用 Go 优雅地实现复杂业务规则？

四、具体的 Go 成长方案 🚀

四周提升计划

Week 1：重新理解 Go 的价值定位

理解 Go 在微服务、高并发中的优势
深入 goroutine 调度和内存管理
用 AI 优化并发处理和配置管理

Week 2：独立实现核心模块

不依赖 AI，手写状态机、分布式锁、订单号生成器
再用 AI 分析改进

Week 3：系统设计与架构

设计秒杀系统的 Go 架构
服务发现机制与监控可观测性
学习分布式事务和一致性保证

Week 4：进阶优化与分享

使用 pprof 进行性能调优
完善代码规范与测试体系
写一篇技术总结或做一次团队分享

五、缓解焦虑的心态调整

重新认识价值：系统思维、架构设计、AI 协作能力，比死记语法更重要。
建立正确对比：和别人比系统设计、业务理解，而不是比谁写得快。
每天复盘：
- 早晨回顾昨天用 AI 解决了什么问题？
- 晚上总结今天在系统思维上的进步。

最重要的是：您不是“没学到”，而是学到了更高价值的东西。

在 AI 时代，高手不是不用 AI 的人，而是最会利用 AI 创造价值的人。

结语

AI 编程确实改变了开发者的学习路径，但这并不意味着学习被削弱，反而意味着学习内容上移到更高层次。别再用旧的语法标准衡量自己，而要关注系统设计、业务建模和 AI 协作能力。

记住：AI 时代，成长的核心不在于写多少行代码，而在于能驾驭多复杂的系统。

AI 时代工程师学习路线图的重构

Tuo Cheng — Fri, 05 Sep 2025 02:30:57 +0000

1. 学习重点的根本转移 📚

不再需要死记硬背的内容 ❌

可以"遗忘"的传统技能:
  命令行语法细节:
    - iptables 复杂规则语法 ❌
    - Docker 命令行参数记忆 ❌  
    - nginx 配置文件语法 ❌
    - 各种框架的API细节 ❌

  编程语法细节:
    - 正则表达式复杂语法 ❌
    - SQL复杂查询语句 ❌
    - 各语言的标准库API ❌
    - 设计模式的标准实现 ❌

  配置管理细节:
    - Kubernetes YAML配置 ❌
    - CI/CD 管道配置语法 ❌
    - 各种工具的配置参数 ❌

为什么不需要？ AI可以瞬间生成正确的语法，您只需要知道"要实现什么目标"。

新的学习重点优先级 ⭐

Tier 1: 核心必修 (80%时间投入)

系统思维与架构设计:
  🎯 分布式系统原理和实践
  🎯 微服务架构设计模式  
  🎯 数据密集型应用设计
  🎯 高可用系统设计
  🎯 性能优化和容量规划

业务建模与领域知识:
  🎯 领域驱动设计(DDD)
  🎯 业务流程分析和优化
  🎯 用户体验设计思维
  🎯 特定行业的深度知识
  🎯 商业模式和价值创造

AI协作与自动化:
  🎯 提示工程和AI对话技巧
  🎯 AI辅助开发工具链
  🎯 自动化测试和部署
  🎯 智能运维和监控
  🎯 AI在特定领域的应用

Tier 2: 重要选修 (15%时间投入)

新兴技术趋势:
  🔸 云原生技术生态
  🔸 边缘计算和IoT
  🔸 区块链技术应用
  🔸 机器学习工程化

跨领域技能:
  🔸 数据科学和分析思维
  🔸 产品设计和用户研究
  🔸 团队管理和沟通技巧
  🔸 创新方法论

Tier 3: 了解即可 (5%时间投入)

基础技术原理:
  🔹 计算机科学基础理论
  🔹 网络协议和安全原理
  🔹 操作系统核心概念
  🔹 算法和数据结构(概念理解即可)

2. AI时代的学习方法革命 🚀

概念优先学习法

传统方法: 语法 → 示例 → 项目
AI时代方法: 概念理解 → AI实现 → 原理验证

学习流程变化:
  第1步: 理解核心概念和设计理念 (30分钟)
  第2步: 用AI生成实现示例 (10分钟)
  第3步: 分析AI实现的优缺点 (20分钟)
  第4步: 针对具体场景优化改进 (30分钟)

总用时: 90分钟掌握新技术基础
vs 传统方法: 2-3天才能开始使用

问题驱动学习法

学习策略:
  从实际问题出发:
    - "如何设计一个支持百万用户的支付系统？"
    - "怎样保证分布式系统的数据一致性？"
    - "如何优化系统的性能瓶颈？"

  而不是:
    - "学习Spring Boot框架"
    - "掌握Redis使用方法"
    - "了解Docker容器技术"

AI辅助深度学习法

AI作为学习助手:
  概念解释: "用简单例子解释CAP定理"
  代码生成: "实现一个简单的分布式锁"
  方案对比: "对比不同的消息队列方案"
  最佳实践: "总结微服务设计的最佳实践"

学习效率提升: 3-5倍
理解深度保持: 通过问题驱动确保深度理解

3. 具体学习资源推荐 📖

系统设计与架构思维

必读经典书籍:

系统设计:
  📚 《设计数据密集型应用》- Martin Kleppmann
     - 分布式系统的圣经
     - 重点理解：一致性、可用性、分区容错
     - 学习方式：概念理解 + AI实现示例

  📚 《微服务架构设计模式》- Chris Richardson  
     - 微服务实战指南
     - 重点：服务拆分、数据管理、通信模式
     - 配合AI：让AI生成不同模式的代码示例

  📚 《架构整洁之道》- Robert C. Martin
     - 软件架构的基本原则
     - 重点：依赖反转、边界划分
     - AI辅助：理解抽象原则，AI实现具体代码

高可用设计:
  📚 《Release It!》- Michael Nygard
     - 生产系统稳定性设计
     - 学习重点：断路器、超时、重试策略

  📚 《Site Reliability Engineering》- Google SRE Team
     - Google的运维实践
     - 免费在线：https://sre.google/books/

在线学习平台:

系统设计课程:
  🌐 Grokking the System Design Interview (educative.io)
  🌐 高可用架构 (极客时间)
  🌐 System Design Primer (GitHub)
     - https://github.com/donnemartin/system-design-primer

视频课程:
  📺 MIT 6.824 分布式系统课程 (免费)
  📺 Designing Data-Intensive Applications 作者讲座

业务建模与领域知识

领域驱动设计(DDD):

核心书籍:
  📚 《领域驱动设计》- Eric Evans (经典理论)
  📚 《实现领域驱动设计》- Vaughn Vernon (实战指导)
  📚 《领域驱动设计精粹》- Vaughn Vernon (快速入门)

实践资源:
  🌐 DDD Community: https://dddcommunity.org/
  🌐 EventStorming: https://eventstorming.com/
  📺 Domain Driven Design Europe 会议视频

用户体验和产品思维:

推荐书籍:
  📚 《用户体验的要素》- Jesse James Garrett
  📚 《精益创业》- Eric Ries  
  📚 《用户故事地图》- Jeff Patton
  📚 《设计思维》- Tim Brown

在线课程:
  🌐 Google UX Design Certificate (Coursera)
  🌐 Human-Computer Interaction (Stanford Online)

AI协作与自动化

AI协作技能:

提示工程:
  📚 《The Art of Prompt Engineering》
  🌐 OpenAI Prompt Engineering Guide
  🌐 Claude Prompt Library: https://docs.anthropic.com/claude/prompt-library

AI开发工具:
  🌐 GitHub Copilot 最佳实践文档
  🌐 Cursor Editor 使用指南
  🌐 V0.dev (Vercel AI) - UI生成工具
  📺 AI-Driven Development YouTube频道

自动化和DevOps:

现代DevOps:
  📚 《凤凰项目》- Gene Kim (DevOps理念)
  📚 《持续交付》- Jez Humble
  🌐 Kubernetes官方文档 (概念理解为主)
  🌐 GitOps工作流程指南

监控可观测性:
  🌐 Prometheus + Grafana 教程
  🌐 OpenTelemetry 实践指南
  📺 Observability Engineering 在线课程

跨领域知识

商业思维:

商业模式:
  📚 《商业模式新生代》- Alexander Osterwalder
  📚 《精益画布》- Ash Maurya
  📚 《从0到1》- Peter Thiel

数据分析:
  📚 《数据科学实战》- Joel Grus
  🌐 Kaggle Learn (免费在线课程)
  📺 3Blue1Brown - 数学直觉可视化

在线学习社区:

技术社区:
  🌐 InfoQ - 深度技术文章
  🌐 High Scalability - 系统设计案例
  🌐 Martin Fowler's Blog - 软件设计思想
  🌐 AWS Architecture Center - 云架构实践

中文优质资源:
  🌐 美团技术团队博客
  🌐 阿里技术博客  
  🌐 字节跳动技术博客
  📱 极客时间 - 系统化课程

4. React学习案例：传统vs AI时代对比 ⚛️

让我用React学习作为详细例子，展示两种学习方式的根本差异：

传统React学习路径 (需要2-3周)

第1周：基础语法掌握

Day 1-2: 环境搭建
  - 安装Node.js、npm、create-react-app
  - 理解项目结构和文件作用
  - 配置开发环境和调试工具
  - 时间消耗：6-8小时

Day 3-5: JSX语法学习  
  - JSX语法规则和转换原理
  - 条件渲染的各种写法
  - 列表渲染和key的使用
  - 事件处理的语法细节
  - 需要背记：JSX转换规则、事件对象属性等
  - 时间消耗：10-12小时

Day 6-7: 组件基础
  - 函数组件vs类组件的写法区别
  - Props的传递和验证
  - State的定义和更新方法
  - 生命周期方法的记忆和使用
  - 需要背记：生命周期顺序、方法名称等
  - 时间消耗：8-10小时

第2周：进阶概念

Day 8-10: Hooks学习
  - useState、useEffect的语法和用法
  - 其他内置Hooks的API记忆
  - 自定义Hooks的编写规则
  - Hooks的规则和限制
  - 需要背记：各种Hooks的参数形式
  - 时间消耗：12-15小时

Day 11-14: 生态系统
  - React Router的路由配置语法
  - Redux的action、reducer写法
  - 各种中间件的配置方法  
  - 第三方UI库的使用方法
  - 需要背记：大量API和配置语法
  - 时间消耗：20-25小时

第3周：项目实践

Day 15-21: 项目开发
  - 从零搭建一个TodoList应用
  - 遇到问题查文档、StackOverflow
  - 调试语法错误和逻辑错误
  - 性能优化和最佳实践学习
  - 时间消耗：30-40小时

总时间投入：80-100小时
主要困难：语法细节多、概念抽象、调试困难
学习成果：能够开发基本的React应用

AI时代React学习路径 (需要2-3天)

Day 1：概念理解和快速上手 (4小时)

上午 (2小时)：核心概念理解
  AI对话内容：
  "解释React的核心设计理念和组件化思想"
  "React的数据流和状态管理是如何工作的？"
  "现代React开发的最佳实践是什么？"

  学习重点：
  ✅ 理解组件化思想和单向数据流
  ✅ 理解虚拟DOM和Diff算法的价值
  ✅ 理解React在前端生态中的定位
  ❌ 不需要记忆JSX语法细节
  ❌ 不需要背诵生命周期方法

下午 (2小时)：AI辅助实践
  AI协作内容：
  "帮我创建一个现代化的React项目模板"
  "生成一个用户管理的CRUD应用示例"
  "解释这段代码的设计模式和最佳实践"

  学习成果：
  ✅ 获得完整可运行的项目代码
  ✅ 理解现代React项目结构
  ✅ 掌握组件设计和状态管理

Day 2：业务场景应用 (4小时)

上午 (2小时)：实际问题解决
  AI协作场景：
  "我需要实现一个支付表单，包含表单验证和状态管理"
  "如何设计一个可复用的数据表格组件？"
  "实现一个购物车功能，支持增删改查"

  学习重点：
  ✅ 理解业务需求到技术实现的转换
  ✅ 学会组件设计和抽象原则
  ✅ 掌握状态管理的最佳实践

下午 (2小时)：架构理解
  AI对话内容：
  "分析这个React应用的架构设计优缺点"
  "如何优化React应用的性能？"
  "React项目的测试策略应该是怎样的？"

  学习成果：
  ✅ 具备架构分析和优化能力
  ✅ 理解性能优化的核心原理
  ✅ 掌握项目质量保证方法

Day 3：深度理解和扩展 (4小时)

上午 (2小时)：生态系统理解
  AI协作内容：
  "对比不同的React状态管理方案的适用场景"
  "分析React Router、Next.js等工具的设计理念"
  "现代React开发工具链是如何工作的？"

  学习重点：
  ✅ 理解技术选型的决策依据
  ✅ 掌握工具链的核心价值
  ✅ 具备技术评估和选择能力

下午 (2小时)：实际项目优化
  基于真实需求：
  "优化我们支付系统的React前端性能"
  "设计一个可扩展的组件库架构"
  "实现前端的错误监控和用户体验优化"

  学习成果：
  ✅ 能够将React应用于实际业务项目
  ✅ 具备系统性的前端架构思维
  ✅ 掌握生产级应用的开发能力

总时间投入：12小时
主要优势：快速理解核心概念，直接应用于实际项目
学习成果：具备React全栈开发和架构设计能力

两种学习方式的深度对比

维度	传统学习	AI时代学习
时间投入	80-100小时	12小时
学习深度	语法细节深入	概念和应用深入
实践能力	基础CRUD应用	生产级应用开发
问题解决	依赖搜索和试错	AI辅助分析和实现
知识保持	容易遗忘语法细节	理解原理，随时可用AI实现
扩展能力	需要重新学习新特性	快速理解和应用新概念

AI时代学习的核心变化

关注点转移：

从 "如何写React代码" → 转向 "如何设计React应用"
从 "记住Hooks的语法" → 转向 "理解状态管理的原理"  
从 "背诵生命周期" → 转向 "掌握组件的设计模式"
从 "调试语法错误" → 转向 "优化用户体验"

学习策略变化：

传统策略：
  1. 系统性学习所有语法
  2. 大量练习和记忆
  3. 遇到问题查文档
  4. 积累经验和最佳实践

AI协作策略：
  1. 快速理解核心设计理念
  2. 用AI生成实践示例
  3. 分析AI生成代码的优缺点
  4. 针对业务需求优化和扩展

技能重点变化：

不再重要的技能：
  ❌ JSX语法细节的记忆
  ❌ API文档的背诵
  ❌ 常见问题的解决套路记忆
  ❌ 各种库的配置语法

新的核心技能：
  ✅ 组件化设计思维
  ✅ 用户体验优化能力
  ✅ 前端架构设计能力
  ✅ 与AI有效协作的能力
  ✅ 技术选型和评估能力

总结：AI时代学习的核心原则

理解 > 记忆: 重点理解设计原理，让AI处理实现细节
问题 > 技术: 从业务问题出发学习，而不是为了学技术而学技术
应用 > 语法: 快速上手实际应用，在使用中深化理解
思维 > 工具: 培养架构思维和设计能力，工具可以替换
协作 > 独立: 学会与AI协作，而不是完全依赖或排斥AI

最重要的观念转变：不要再为记不住iptables语法而苦恼，应该为不理解系统安全架构设计而担忧！

AI时代的工程师价值在于："我知道要解决什么问题，以及如何设计最优的解决方案"，而不是"我能手写出复杂的配置文件"。

AI编程时代：软件工程师能力要求的深度变革

Tuo Cheng — Fri, 05 Sep 2025 02:10:15 +0000

引言

我们正站在软件开发历史的一个重要转折点。随着大型语言模型和AI编程助手的快速发展，软件工程师的日常工作方式正在发生根本性变化。从GitHub Copilot到Claude、ChatGPT等AI助手的普及，"写代码"这一核心技能的定义正在被重新审视。

本文基于我们团队在AI编程领域的实践经验，深入分析这一变革对软件工程师能力要求带来的影响，并为处在转型期的工程师提供实用的发展建议。

传统开发时代的能力金字塔

1. 基础技能层：语法与工具熟练度

在传统开发时代，工程师能力的基石是对编程语言的深度掌握：

语言语法精通

熟练掌握多种编程语言的语法细节
理解语言特性和最佳实践
能够手写复杂的算法和数据结构

开发工具熟练度

IDE快捷键的肌肉记忆
调试器的深度使用
构建工具和包管理器的配置

"八股文"能力

手写快速排序、红黑树等经典算法
背诵设计模式的标准实现
熟记各种框架的API和配置方式

2. 中级技能层：框架与架构理解

框架深度使用

阅读和理解框架源码
自定义扩展和插件开发
性能优化和故障排查

系统设计能力

数据库设计和优化
分布式系统架构
微服务拆分和治理

3. 高级技能层：业务理解与技术领导

业务逻辑建模

深入理解业务需求
将业务规则转换为技术实现
跨部门沟通协调

技术决策与领导

技术选型和架构决策
代码审查和质量把控
团队技术培训和指导

AI时代的新能力模型

1. 核心能力重新定义：从"实现"到"设计"

系统设计思维 （原高级技能下沉为核心技能）

传统：业务需求 → 技术方案 → 详细设计 → 编码实现
AI时代：业务需求 → 系统设计 → AI协作实现 → 业务验证

工程师的核心价值从"如何实现"转向"实现什么"和"为什么这样实现"。

业务建模能力 （重要性显著提升）

深度理解业务领域和规则
将复杂业务逻辑抽象为清晰的系统模型
识别业务流程中的关键决策点和异常处理

架构思维 （从中级技能提升为核心技能）

模块边界的清晰定义
数据流和控制流的设计
可扩展性和可维护性的前瞻考虑

2. 新兴关键技能：AI协作能力

提示工程 （全新技能）

精准描述技术需求的能力
结构化问题分解和表达
迭代式需求细化和优化

优秀的提示工程示例：
需求描述: "设计一个用户认证系统"
细化为: 
  - 认证方式：JWT + 刷新令牌机制
  - 安全要求：密码加密、防暴力破解、会话管理
  - 扩展性：支持多种认证源（邮箱、手机、第三方OAuth）
  - 错误处理：详细的错误码和用户友好的错误信息
  - 技术栈约束：Node.js + Express + MongoDB

AI输出验证与优化

快速理解AI生成代码的逻辑
识别AI生成代码中的潜在问题
基于业务需求优化AI的输出结果

人机协作流程设计

确定哪些部分适合AI生成，哪些需要人工设计
建立高效的AI辅助开发工作流
在团队中推广和优化AI协作模式

3. 质量保证能力：从代码审查到业务验证

业务逻辑验证 （重要性大幅提升）

传统代码审查关注：
- 语法错误 ❌（AI基本不会犯）
- 代码风格 ❌（AI自动遵循）
- 性能问题 ⚠️（AI通常较优）

AI时代审查重点：
- 业务逻辑正确性 ✅
- 边界条件处理 ✅  
- 安全和合规性 ✅
- 系统集成兼容性 ✅

测试设计能力

基于业务场景设计测试用例
自动化测试策略的制定
AI生成代码的专项测试方法

具体能力变化对比分析

1. 学习方式的革命性变化

维度	传统开发	AI辅助开发
文档阅读	深度阅读API文档、教程	快速浏览概览，通过AI验证细节
语法学习	系统性学习语言特性	按需学习，AI辅助语法纠错
最佳实践	背诵和模仿经典代码	理解原理，让AI实现最佳实践
调试技能	断点调试、日志分析	问题描述 + AI辅助分析

实际案例对比：

传统学习新框架的过程：

1. 阅读官方文档（2-3天）
2. 跟随教程写Hello World（半天）
3. 阅读源码理解原理（1-2天）
4. 练习各种场景应用（1周）
5. 总计：约2周才能熟练使用

AI辅助学习新框架：

1. 了解框架核心概念（2小时）
2. 通过AI生成示例代码（30分钟）
3. 理解AI生成的代码逻辑（1小时）
4. 针对具体需求迭代优化（1天）
5. 总计：2-3天即可投入生产使用

2. 问题解决思维的转变

传统问题解决流程：

graph TD
    A[遇到问题] --> B[搜索Stack Overflow]
    B --> C[阅读相关文档]
    C --> D[分析其他人的代码]
    D --> E[自己手写解决方案]
    E --> F[调试和优化]

AI辅助问题解决：

graph TD
    A[遇到问题] --> B[描述问题给AI]
    B --> C[分析AI提供的方案]
    C --> D[评估方案适用性]
    D --> E[让AI生成/优化代码]
    E --> F[验证业务逻辑正确性]

3. 技术深度与广度的平衡

传统开发：深度优先

专精1-2种编程语言
深度掌握特定技术栈
成为某个领域的"专家"

AI时代：广度与洞察力并重

快速跨越多种技术栈
重点培养业务洞察能力
成为"技术产品经理"角色

给工程师的转型建议

1. 立即开始的能力转型

培养系统性思维

建议实践：
  - 每个项目都从系统设计图开始
  - 学习领域驱动设计（DDD）方法论
  - 练习将业务需求抽象为技术模型
  - 多读业务流程相关的书籍和案例

提升业务理解能力

实用方法：
  - 主动参与产品需求讨论
  - 了解公司的商业模式和核心指标
  - 阅读行业报告和竞品分析
  - 与业务人员建立定期沟通机制

掌握AI协作技巧

实践步骤：
  第一阶段: 用AI辅助重复性编码任务
  第二阶段: 用AI进行代码重构和优化  
  第三阶段: 用AI协作设计系统架构
  第四阶段: 建立团队AI协作规范

2. 中期发展重点

成为业务技术专家

深入了解特定行业的技术特点
积累领域特定的最佳实践经验
能够为业务决策提供技术建议

建立AI时代的技术影响力

分享AI协作的最佳实践
帮助团队建立AI辅助开发流程
成为AI工具和技术的内部推广者

3. 长期职业规划

技术产品经理方向

具备技术背景的产品设计能力
能够在技术可行性和业务价值间找到平衡
推动技术驱动的产品创新

技术架构师方向

系统级的设计和决策能力
跨团队的技术协调和推动
AI时代的架构最佳实践制定者

创业/技术创新方向

利用AI工具快速验证技术想法
以更低成本实现技术产品化
成为AI原生技术产品的创造者

不同经验层次工程师的转型策略

初级工程师（0-2年）

优势：

没有传统开发的思维包袱
更容易接受AI协作模式
学习新技术的灵活性强

转型重点：

核心能力培养：
  - 系统性思维训练（通过项目实践）
  - 业务理解能力（多参与需求讨论）
  - AI协作技能（成为团队AI使用的先锋）

避免的陷阱：
  - 过度依赖AI，缺乏基础理论理解
  - 忽视代码质量和业务逻辑验证
  - 缺乏全栈思维和系统概念

中级工程师（2-5年）

优势：

有一定的系统开发经验
理解业务和技术的结合点
具备一定的团队协作能力

转型挑战：

需要突破的局限：
  - 习惯于手写代码的开发模式
  - 对AI生成代码质量的不信任
  - 担心AI替代自己的价值

转型策略：
  - 逐步将AI集成到现有工作流程
  - 重点提升架构设计和业务建模能力
  - 成为团队AI协作流程的设计者

高级工程师（5年以上）

优势：

深厚的技术积累和经验
强大的问题解决能力
团队领导和技术决策经验

转型重点：

价值重新定位：
  - 从"技术专家"转向"技术战略家"
  - 利用AI扩展技术边界，而非被AI替代
  - 将经验转化为AI协作的最佳实践

新的价值创造：
  - 设计AI无法替代的系统架构决策
  - 培养下一代AI协作型工程师
  - 推动技术组织的AI转型

组织和团队层面的变化

团队结构的演进

传统开发团队：

技术Leader (1) 
├── 高级工程师 (2-3)
├── 中级工程师 (3-4)
└── 初级工程师 (2-3)

专业分工明确：前端/后端/测试/运维

AI时代团队结构：

技术产品经理 (1)
├── 系统架构师 (1)
├── AI协作专家 (2-3)
├── 业务逻辑专家 (2-3)  
└── 质量保证专家 (1-2)

职能更加融合：全栈化 + 业务化

协作方式的变化

决策制定方式：

传统：技术专家主导 → AI时代：业务价值主导
传统：经验驱动决策 → AI时代：数据+实验驱动

知识分享模式：

传统：代码示例 + 技术文档
AI时代：提示词模板 + 业务场景库

质量保证机制：

传统：代码审查 + 测试用例
AI时代：业务逻辑验证 + AI输出质量评估

技术栈学习策略的根本改变

传统技术栈学习路径

graph TD
    A[选择技术栈] --> B[系统学习基础语法]
    B --> C[练习基础项目]
    C --> D[学习框架和库]
    D --> E[阅读最佳实践]
    E --> F[项目实战应用]
    F --> G[深度优化和扩展]

时间成本： 每个新技术栈需要1-3个月深度学习

AI时代的快速上手策略

graph TD
    A[了解技术栈核心概念] --> B[用AI生成基础项目模板]
    B --> C[理解AI生成的代码结构]
    C --> D[针对具体需求迭代优化]
    D --> E[积累领域特定的提示词]
    E --> F[形成AI协作最佳实践]

时间成本： 每个新技术栈2-7天即可投入生产开发

学习重点的转移

从"How"到"What"和"Why"：

传统学习关注：
  - 如何配置开发环境？
  - 如何写Hello World？  
  - API怎么调用？
  - 常见问题如何解决？

AI时代学习关注：
  - 这个技术栈适用于什么场景？
  - 核心架构理念是什么？
  - 与其他技术栈相比的优劣势？
  - 在我的业务场景中如何应用？

面向未来的技能投资建议

1. 优先投资的"AI难以替代"技能

创造性思维

培养方式：
  - 参与开源项目，贡献创新想法
  - 尝试将AI应用于非传统领域
  - 定期进行技术趋势分析和预测
  - 跨领域学习，寻找技术融合机会

复杂问题分解能力

实践方法：
  - 练习将复杂业务需求拆解为清晰的技术任务
  - 学习系统性思维方法（如系统思考、设计思维）
  - 参与复杂系统的架构设计和重构项目
  - 培养抽象思维和模型建立能力

跨领域知识整合

知识扩展方向：
  - 业务领域知识（金融、医疗、教育等）
  - 用户体验和产品设计
  - 数据分析和商业智能
  - 新兴技术趋势（区块链、IoT、边缘计算）

2. 需要重新评估的传统技能

部分保留的技能：

算法思维（重要性下降，但仍需基础理解）
性能优化（AI可以协助，但需要人工判断）
安全意识（更加重要，AI可能引入新的安全风险）

可以降低投入的技能：

语法细节记忆（AI可以处理）
重复性编码技巧（AI更擅长）
特定框架的深度API知识（AI可以查询和应用）

3. 新兴技能的投资建议

AI协作技能 (高优先级)

投资建议：
  - 时间投入：每周5-10小时
  - 学习方式：项目实践 + 经验分享
  - 成果指标：AI协作效率提升2-3倍

业务建模能力 (高优先级)

投资方向：
  - 领域驱动设计（DDD）
  - 业务流程分析
  - 用户需求洞察
  - 商业模式理解

系统架构思维 (中高优先级)

培养路径：
  - 参与大型系统设计
  - 学习分布式系统理论
  - 实践微服务架构
  - 云原生技术应用

行业前景与机会

新兴职业方向

AI协作工程师

专门负责优化人机协作流程
设计AI辅助开发的最佳实践
培训团队AI协作技能

技术产品经理

结合深度技术背景和产品思维
在AI工具辅助下快速验证技术产品想法
成为技术驱动创新的关键角色

业务系统架构师

深度理解特定行业的业务逻辑
设计满足复杂业务需求的技术架构
在AI协助下快速实现架构落地

薪资和职业发展趋势

基于行业观察，AI时代的工程师薪资分化会更加明显：

高价值工程师（薪资增长）

能够有效利用AI工具提升效率的工程师
具备强业务理解能力的技术专家
能够设计和管理AI协作流程的团队leader

面临挑战的工程师（薪资压力）

纯粹的编码执行者
拒绝学习AI协作的传统开发者
缺乏业务理解的纯技术型工程师

总结与展望

AI编程的普及正在重新定义软件工程师这一职业。我们正从"代码工人"向"数字产品设计师"转变，从"语法专家"向"业务架构师"进化。

这个转变既是挑战，更是机遇。那些能够主动拥抱AI、快速调整能力结构的工程师，将在这个新时代中获得更大的职业发展空间和价值创造机会。

关键要点回顾：

核心能力转移：从编码实现转向系统设计和业务建模
学习方式革命：从深度学习语法转向快速理解概念和AI协作
价值创造重心：从技术实现转向业务价值和用户体验
职业发展路径：技术产品经理、业务架构师、AI协作专家等新方向

给工程师的最终建议：

立即行动：开始在日常工作中集成AI工具
持续学习：重点提升系统思维和业务理解能力
积极分享：将AI协作经验总结为团队最佳实践
保持开放：这个变革才刚刚开始，保持学习和适应的心态

未来属于那些能够与AI协作创造价值的工程师。让我们一起迎接这个充满可能性的新时代！

如果你对AI编程实践有自己的见解，欢迎在评论区分享交流。让我们共同探索AI时代软件开发的最佳实践。

相关阅读推荐：

《系统思考》- Peter Senge
《领域驱动设计》- Eric Evans
《精益创业》- Eric Ries
《架构整洁之道》- Robert C. Martin

AI 开发让团队头疼的 Git 冲突，怎么破？

Tuo Cheng — Fri, 05 Sep 2025 02:09:09 +0000

随着 AI 编程在团队开发中的普及，Git 冲突的发生频率显著增加。这不仅是技术层面的问题，更是协作方式的挑战。本文将深入剖析 AI 开发中冲突频发的原因，并提出相应的解决方案和团队实践。

一、为什么 AI 开发更容易产生冲突？

1. 大范围重构的倾向

传统开发者往往只在某个函数或模块内做小改动，而 AI 在优化时常常会“顺便”重构整个函数，甚至调整相关依赖。这导致即便初衷只是小修改，结果却可能引发大范围差异。

2. 实现方式的多样性

同一个需求，开发者 A 的 AI 可能生成 Repository 模式，开发者 B 的 AI 可能选择直接数据库访问。两者逻辑都对，但实现完全不同，合并时必然冲突。

3. “重新实现”的偏好

AI 更倾向于生成新的“更优版本”，而不是在原代码上逐步修补。于是同一功能在不同分支上可能出现多个完全不同的版本，冲突变得难以调和。

二、传统开发与 AI 开发的冲突对比

维度	传统开发	AI 开发
冲突范围	局部（几行代码）	整体（函数/文件级重构）
冲突类型	逻辑冲突	实现方式冲突
冲突频率	相对较低	显著增高
解决难度	简单合并	需重新设计

传统开发的冲突往往是几行日志或条件判断，简单合并即可。而 AI 开发的冲突往往涉及函数签名、架构模式的完全不同，难以通过常规方式解决。

三、AI 开发时代的冲突解决方案

方案 1：模块/服务级别的开发隔离

明确每个开发者和 AI 负责的模块，禁止跨界随意修改。

好处：减少多人在同一模块上发生冲突。
风险：接口变更需额外沟通。

方案 2：接口优先策略

在编码前，先由团队统一接口定义，AI 只能在接口内部生成实现。

好处：避免函数签名冲突。
风险：需要提前花时间开设计会议。

方案 3：分层开发

按照 API 层、业务逻辑层、数据访问层、基础设施层划分责任。

好处：降低同一层被多人修改的概率。
风险：层间依赖关系必须管理清晰。

方案 4：AI 使用规范化

通过提示词和约束来统一 AI 输出风格。

统一命名规则、错误处理方式、日志格式。
AI 只能修改指定文件或函数，禁止随意重构公共部分。
所有 AI 生成代码必须经过人工审查。

方案 5：技术手段辅助

配置 Git 的更优合并策略（如 diff3、patience 算法）。
使用 pre-commit hook 检查 AI 代码规范性。
强制格式化工具（如 gofmt、Prettier）保证风格一致。

四、AI 协作时代的工作流程建议

为了适应 AI 大规模参与开发，团队需要新的 Git 流程：

graph TD
    A[需求分析] --> B[接口设计会议]
    B --> C[任务分工]
    C --> D[AI 辅助开发]
    D --> E[自测验证]
    E --> F[代码审查(逻辑为主)]
    F --> G[集成测试]
    G --> H[合并主分支]

关键环节说明：

接口设计会议：先确定不可变更的契约。
任务分工：按模块或层次划分，避免多人同时修改同一部分。
AI 协作开发：限制 AI 修改范围，保持一致的提示词。
逻辑审查优先：代码审查重心从语法细节转移到业务逻辑正确性。

五、结论：预防优于修复

在 AI 编程时代，冲突频繁已是常态。与其依赖更复杂的合并工具，不如通过 前置的接口设计、严格的分工与 AI 使用规范 来减少冲突的发生。

一句话总结：
AI 开发中的 Git 协作，需要从“冲突后修复”转向“事前预防”。

AI 编程与传统开发的系统性比较

Tuo Cheng — Fri, 05 Sep 2025 01:47:57 +0000

随着人工智能在软件工程中的广泛应用，AI 编程逐渐成为开发团队的新工具和新范式。与传统手工编程相比，AI 驱动的开发模式不仅带来了效率提升，也正在重塑团队协作方式。以下从几个关键维度进行比较。

1. 开发效率与迭代速度

AI 编程

能快速生成项目骨架和样板代码，缩短从构思到原型的时间。
在重复性任务中，如数据模型定义、接口编写、单元测试等，AI 可以批量生成，避免人工重复劳动。
文档和代码往往能够同步生成，降低“代码先于文档”的滞后问题。

传统编程

每个模块都需人工搭建和维护，迭代速度较慢。
重复性工作需人工完成，效率低下。
文档通常依赖开发者自觉，存在遗漏和滞后的风险。

2. 代码质量与一致性

AI 编程

能稳定执行预设的规范，如统一命名规则、代码风格和架构模式。
通过大量训练语料，AI 生成的代码更符合“最佳实践”，降低低级错误出现率。
在大规模项目中，AI 有助于保持风格一致，减少团队内部的差异化。

传统编程

风格和质量受个人习惯影响较大，需要团队额外投入在代码规范化和审查上。
容易因人为疏忽导致小错误累积成大问题。

3. 复杂逻辑与业务实现

AI 编程

可以根据自然语言描述，快速生成复杂逻辑的代码雏形。
在风控、数据处理、并发架构等高复杂度领域，AI 能给出参考实现，帮助开发者减少从零开始的负担。
善于生成异步处理、消息队列等现代架构的常见模式。

传统编程

更依赖开发者的专业经验和领域知识。
复杂逻辑实现常常需要大量试错与讨论，效率相对较低。

4. 技术栈学习与跨界整合

AI 编程

帮助开发者快速上手陌生框架或语言，生成符合惯例的代码。
能够跨语言、跨平台提供支持，如同时生成后端接口、前端组件与部署脚本。
更容易跟进最新的框架特性和最佳实践。

传统编程

学习和使用新技术需要较长周期。
不同技术栈常常需要专业化分工，跨栈整合难度较大。

5. 调试与问题解决

AI 编程的挑战

代码逻辑可能存在“黑盒性”，调试时需要额外时间理解生成意图。
若过度依赖 AI，开发者对底层原理的掌握可能不足。
在复杂系统中，定位 AI 生成代码的 bug 可能更困难。

传统编程的优势

开发者对自己编写的代码有更清晰的理解。
调试更直观，同时有助于积累经验与技能。

6. 团队协作模式的变化

AI 编程时代

代码审查的重点从语法细节转向业务逻辑正确性。
团队成员之间可以共享提示词（Prompt）和生成模板，形成新的知识传递方式。
开发者的角色逐渐转向架构设计、业务分析与质量把控。

传统团队协作

代码审查涉及风格、语法和逻辑的全方位检查。
知识共享主要依赖文档、示例和培训。
开发者更多精力放在具体实现与细节敲定上。

结论与建议

AI 编程并不是对传统编程的取代，而是一次开发模式的升级。它显著提高了效率与一致性，但在关键环节仍需要人工的经验和判断。

更合理的做法是：

将 AI 应用于非关键模块和重复性任务，释放开发者的创造力。
在核心逻辑上保持人工把控，尤其是涉及安全性、资金流或业务核心的部分。
建立完善的测试与审查机制，让 AI 与人工优势互补。

未来的软件开发将是 AI 与人类协作 的过程：AI 负责速度与规模，人类负责方向与判断。

Go 常用命令

Tuo Cheng — Wed, 20 Aug 2025 05:37:40 +0000

核心开发命令 (每天都会用到)

go run: 编译并直接运行
- 作用：这是一个“懒人”命令。它会先将你的 Go 源代码编译成一个临时的可执行文件（放在一个临时目录里），然后立刻运行这个程序。程序结束后，这个临时文件会被自动删除。
- 通俗解释：就像你在 IDE 里点击“运行”按钮。它帮你省去了“先编译、再运行”这两个步骤，非常适合在开发和调试时快速查看代码效果。
- 示例：go run main.go
go build: 只编译，不运行
- 作用：将 Go 源代码编译成一个可执行的二进制文件，并把它放在你当前所在的目录或指定的输出目录（使用 -o 参数）。它只做编译这一件事，不会运行程序。
- 通俗解释：就像工厂里的“生产”环节。你把原材料（源代码）给它，它生产出产品（可执行文件），然后你可以把这个产品拿去任何地方使用（运行）。这个命令用于正式构建你的应用，准备部署。
- 示例：go build ./cmd/server (在当前目录生成一个名为 server 的文件) 或 go build -o bin/app ./cmd/server (在 bin 目录下生成一个名为 app 的文件)。
go install: 编译并“安装”到指定位置
- 作用：它比 go build 多做一步。它也会编译源代码，但它会把生成的可执行文件移动到你的 GOPATH/bin 目录或者 GOBIN 环境变量指定的目录。这样，你就可以在系统的任何地方直接通过名字运行这个命令了（前提是你已经将那个 bin 目录添加到了系统的 PATH 环境变量中）。
- 通俗解释：不仅“生产”出产品，还帮你把产品放到了一个“全局货架”上。这样你不管在哪个房间（哪个目录），都能直接拿到这个产品来用，而不需要跑回生产车间（项目目录）。
- 示例：go install ./cmd/server (编译后，server 可执行文件会出现在 GOPATH/bin 中)。

包管理命令 (管理项目依赖)

go get: 下载并安装包
- 作用：用于下载指定的第三方库（包）到你的本地。在 Go Modules 模式下，它会自动更新你的 go.mod 和 go.sum 文件来记录这个新的依赖。
- 通俗解释：就像给你的项目“采购零件”。项目需要一个新功能（比如操作 Redis），你就用 go get 去“采购”一个现成的 Redis 库回来。
- 示例：go get github.com/go-redis/redis/v8
go mod tidy: 整理依赖
- 作用：这是 Go Modules 中非常重要的一个命令。它会检查你所有的 .go 源代码文件，找出你 import 了哪些包，然后：
  - 移除 go.mod 文件中你没用到的依赖。
  - 添加 go.mod 文件中你用到了但缺失的依赖。
  - 确保 go.sum 文件与 go.mod 和实际代码需求完全同步。
- 通俗解释：就像一个“仓库管理员”。它会盘点你的项目到底需要哪些“零件”，然后把多余的清走，把缺少的补上，保证你的“库存清单” (go.mod) 和实际库存 (go.sum) 是完全准确的。在提交代码前执行一次这个命令是个好习惯。
- 示例：go mod tidy

代码质量与工具命令

go fmt: 格式化代码
- 作用：自动按照 Go 官方推荐的风格来格式化你的代码，比如调整缩进、空格等。它不改变代码逻辑，只改变外观。
- 通俗解释：一个“代码洁癖整理师”。不管你的代码写得多乱，它都能一键帮你整理得整整齐齐，符合统一的“收纳标准”。这让团队协作变得非常愉快，因为所有人的代码风格都一样。
- 示例：go fmt ./... (格式化当前目录及所有子目录下的 .go 文件)。
go test: 运行测试
- 作用：执行项目中的测试代码（也就是 _test.go 结尾的文件）。它可以帮你验证代码的正确性。
- 通俗解释：一个“质量检测员”。它会运行你编写的各种测试用例，确保你写的每个函数、每个模块都按预期工作，没有 bug。
- 示例：go test ./... (运行所有测试)。
go vet: 静态代码分析
- 作用：检查代码中可能存在的潜在问题或不符合 Go 语言惯用法的写法。比如，它可能会发现一个 Printf 格式化字符串和后面的参数数量不匹配等 go build 检查不出来的逻辑错误。
- 通俗解释：一个经验丰富的“代码审查员”。它在你运行代码之前，先帮你过目一遍，凭借它的经验，指出一些可能出问题的地方，提醒你注意。
- 示例：go vet ./...

总结与区分

命令	编译?	运行?	生成文件位置	主要用途
`go run`	✅	✅	临时目录 (自动删除)	开发调试，快速验证
`go build`	✅	❌	当前目录或指定目录	构建应用，准备部署
`go install`	✅	❌	`GOPATH/bin` 或 `GOBIN`	安装工具或库到全局
`go mod tidy`	❌	❌	无 (修改 `go.mod`/`go.sum`)	整理和同步项目依赖

接手 AI 项目 5 步流程

Tuo Cheng — Wed, 13 Aug 2025 12:58:19 +0000

在现实中，越来越多的项目会用 AI 辅助写代码，这能显著提高产出速度，但也会带来新的问题：

结构可能混乱
命名和风格不一致
边界条件未处理
文档缺失

当你“空降”接手这样一个已经写了大量代码的项目，如果贸然下手，很容易陷入“边写边踩坑”的循环。

我总结了一个 5 步流程，帮助你快速熟悉项目并降低踩坑风险，尤其适合 AI 生成代码比例较高的项目。

1. 建立项目全局认知（先跑起来）

目标：在不修改代码的情况下，确认项目的用途、功能范围、运行方式。

执行要点：

阅读 README / 文档（如果有），重点关注安装、运行、部署说明。
按推荐方式在本地或测试环境跑通项目，确保依赖、密钥、配置文件齐全。
逆向搞清楚系统的设计（例如画出系统结构简图），至少明确以下细节：
- 前端与后端的技术栈
- 核心模块（API 服务、任务队列、数据库、链交互等）
- 数据流向（例如：用户请求 → 业务逻辑 → 数据库/区块链）
- 所依赖的框架、库、第三方 API、数据库、消息队列等外部服务。

2. 建立代码层次认知（画模块地图）

目标：弄清代码放在哪、模块之间的调用关系。

执行要点：

按目录结构梳理模块功能（例如 src/payments/ 处理支付，src/users/ 管理用户）。
找到项目入口文件：后端如 main.go / server.js，前端如 App.jsx / main.tsx。
绘制核心调用关系（可用简单箭头）：
- API → 控制器 → 服务层 → 数据访问层
- 事件监听 → 处理器 → 数据库/区块链
记录 AI 代码常见特征：冗余函数、未使用变量、命名不一致——先标记，暂不处理。

3. 验证现有功能（黑盒测试）

目标：区分可用功能与存在问题的功能。

执行要点：

列出功能清单：API 路由、UI 页面、后台功能。
用 Postman 或浏览器直接调用 API，验证响应与预期是否一致。
记录 bug 与疑问，尤其关注：
- 链交互
- 异步任务
- 结算逻辑
与业务方确认哪些流程是核心，哪些只是试验性功能。

提示：测试不仅是找 bug，更是帮你建立“这部分能放心用”的信心。

4. 制定开发策略（改造 vs 复用）

目标：明确哪些模块保留、重构或重写，避免全盘推翻或盲目复用。

执行要点：

可直接复用：逻辑简单且已验证可用的模块（如加密工具、UI 组件）。
需要重构：
- 无测试覆盖
- 命名混乱、重复代码
- 复杂逻辑缺少注释
立即修复：安全漏洞（硬编码密钥、SQL 注入）、明显 bug。
推迟优化：性能调优、统一代码风格等可放在后续迭代。

5. 增量开发（边熟悉边改）

目标：在交付新功能的同时，逐步提升代码质量。

执行要点：

每加一个新功能时，对涉及的旧代码进行小步重构。
为高风险模块（链上监听、账本计算、支付回调等）补充单元测试。
改过的部分必须补充 README 或注释，避免延续无文档状态。
每周回顾：新增功能、踩过的坑、下周改进计划。

接手 AI 项目的额外技巧

全局搜索：用 IDE 搜索函数名/变量，快速定位调用位置。
追溯历史：查看 commit message 理解功能演变（如果有版本管理）。
模块隔离实验：单独运行模块测试，避免全系统运行调试成本高。

结语

接手 AI 项目，最怕的是一头扎进细节却对整体一无所知。按照这 5 步走，你可以先建立全局视野，再逐步深入，做到快速上手 + 稳健推进。

架构设计关键产出

Tuo Cheng — Wed, 13 Aug 2025 12:45:39 +0000

在很多团队里，“架构设计”这个词听起来很高级，但真正落地时却变成了“开个会画两张图，然后就开工写代码”。结果是，开发过程中不断返工，模块边界模糊，技术决策摇摆，产品上线一团糟。

问题的根源在于——架构设计阶段缺乏明确的产出要求。到底要产出什么，才能说“架构设计完成”？

我结合实际项目经验，总结了一份技术架构与开发准备阶段的 12 项关键成果。明确了这 12 项，你的项目就能从一开始走得很稳。

一、架构设计类产出

让所有人看得懂系统长什么样、怎么跑、核心流程如何走。

1. 系统总体架构图

形式：一张包含前端、后端、区块链交互层、数据库、缓存、消息队列、外部服务的架构图（draw.io、Mermaid、Visio 都可）。
要求：
- 模块边界清晰（商户后台、API 网关、支付服务、账本、风控等分开画）。
- 每个模块标注主要职责。
- 显示依赖关系（箭头表示数据/事件流向）。
目标：任何新加入的研发，看这张图就能知道整个系统有哪些组件、怎么通信。

2. 关键业务流程图

形式：时序图 / 流程图（支付流程、结算流程、风控拦截流程至少各一张）。
要求：
- 明确参与方（商户、用户、API、链上监听、账本、回调）。
- 按时间顺序展示每一步动作和状态变化。
目标：任何人照图就能复现一次完整支付/结算过程。

3. 接口规范（API 设计文档）

形式：OpenAPI 3.0 / Swagger 文件，或 Markdown 表格。
要求：
- 列出每个接口的 URL、HTTP 方法、请求参数、返回字段、错误码。
- 定义签名和鉴权机制（API Key / OAuth）。
- 指定字段格式（金额、币种、时间戳等）。
目标：商户和前端可以直接按文档调 API，无需口头解释。

4. 数据库与账本设计

形式：ER 图 + 建表 SQL。
要求：
- 列出所有核心表（商户、订单、账本、结算、风险日志、Webhook 日志等）。
- 指明字段类型、索引、外键关系。
- 账本系统需有双分录规则说明（资产增减的记账逻辑）。
目标：后端开发可以直接按图建表，账务逻辑统一。

5. 事件与消息队列定义

形式：事件主题清单（Topic）+ 消息格式说明。
要求：
- 列出每个事件名（如 payment.tx.detected、payment.intent.succeeded）。
- 定义消息体 JSON 字段及含义。
- 指明事件生产方和消费方。
目标：不同服务之间的异步通信有标准格式，避免临时约定。

6. 链上监听与确认策略

形式：参数表 + 流程图。
要求：
- 确认区块数、监听超时时间、地址生成策略、金额误差容忍度等。
- 链上数据如何触发内部账本更新的步骤。
目标：区块链交互有统一规则，减少漏单/重复入账风险。

7. 风控与合规规则文档

形式：规则清单（Excel / Markdown）。
要求：
- 黑名单来源和更新频率。
- 高风险交易判定条件（金额、地理位置、交易模式）。
- 触发后的处理动作（冻结、人工审核、拒绝）。
目标：研发和合规部门共用一份规则，系统实现有明确依据。

二、开发优先级产出

目标是明确先做什么，后做什么，避免范围失控，让团队聚焦核心功能交付。

8. MVP 范围与阶段目标

形式：表格或一页 PDF
内容：
- MVP 要实现的功能（收款 API、链上监听、商户后台订单查询等）
- 明确不做的功能（法币结算、多链支持等）
- 阶段目标和验收条件（如：“支持 TRC20-USDT 支付，商户能收到成功回调，账本余额一致”）

9. 迭代计划 & 优先级排序

形式：甘特图 / Sprint Backlog 表格
内容：
- 按优先级列出功能模块（先做 API & 链上监听 → 再做账本与回调 → 再做风控与结算）
- 每个阶段产出物和预计时间
- 明确哪些模块可并行开发，哪些有依赖

三、技术选型产出

目标是提前定好技术路线，避免中途换技术导致返工。技术决策透明化、标准化，降低沟通成本。

10. 技术栈选型文档

形式：Markdown 文档或表格
内容：
- 后端语言（Go / Node.js / Python）及选择原因（性能、团队经验、生态）
- 前端框架（React/Vue）、UI 库
- 数据库（PostgreSQL/MySQL）、缓存（Redis）
- 区块链 SDK（Web3.js / ethers.js / TronWeb）
- 消息队列（Kafka / RabbitMQ）
- 云服务 / 部署方案（Kubernetes / Docker / 云厂商）

11. 技术标准与规范

形式：团队开发规范文档
内容：
- API 命名、版本管理规范
- 代码风格（lint、格式化工具）
- Git 分支与提交规范
- 环境变量与密钥管理规则

12. 基础设施规划

形式：环境对照表 + 架构草图
内容：
- 开发、测试、预发布、生产环境的域名、链、配置
- CI/CD 流程说明（代码 → 构建 → 测试 → 发布）
- 监控与日志方案（Prometheus、Grafana、ELK）

常见问题

A：是不是这 12 项都做完才能写代码？
Q：不必一次做完，可以分阶段完成。总体架构图、MVP 范围、技术栈选型、核心业务流程图需要在启动开发前明确好，其他可在开发过程中完善。这样既能快速启动，又能逐步完善设计，保持项目的灵活性和可控性。