导言
AI 相关需求经常采用敏捷方式推进：先完成最小穿刺，遇到问题再解决问题。这种方式可以快速消除技术未知，却容易留下另一类债务：需求散落在聊天和 issue 中，关键取舍没有 ADR，安全与可靠性只在事故后出现，性能结果只有一张截图，最终很难回答“你究竟设计了什么，为什么这样设计，怎样证明它有效”。
任职要求要看的不是文档篇幅，而是从问题到结果的可复核判断链。一份合格的软件设计材料应该同时连接需求/Top 问题、架构视图、质量属性场景、候选方案、设计原则与模式、代码提交、测试/Profiling/运行证据，以及后续架构治理。缺失的环节应如实列为设计或代码工作，不能由 AI 根据最终代码补写成虚构的事前决策。
本文解释 4+1 视图、设计原则、GoF 23 个设计模式（不是 24 个）、安全威胁分析、可靠/可用性、可测试性、功能安全、体验、性能、架构治理和技术决策，并给出一个可复用的本地 Skill：输入需求和穿刺代码 commits，输出软件设计文档、任职举证报告、追踪矩阵与缺口清单。
导言
AI 技术更新很快，日常知道“最近出现了什么”并不难，真正困难的是判断：新技术到底解决了旧方案的哪个瓶颈，会替代什么、保留什么、把成本转移到哪里，以及它是否适合自己的用户、硬件和组织。
技术洞察因此不能止于论文、新闻、功能和融资信息的汇总。它要从一个具体决策出发，建立现有技术基线，读标准和代码，设计最小 Demo 与受控基准，量化瓶颈，评估技术演进、成熟度、全生命周期成本和风险，最后给出带适用边界、证据等级和退出条件的行动建议。
本文把技术全景扫描、竞品与标杆、代码与架构逆向、实验与基准、瓶颈、演进、成熟度、成本收益和风险九类方法组织成一个闭环，并沉淀为可复用的 $technology-insight Skill。
导言
功能分解的目标，是把“提升训练问题定位效率”这类高层目标，逐层转成可以独立实现、独立验证、能够追溯业务价值的子功能。真正困难的不是把一个大框画成很多小框，而是保持三种关系清楚：功能树表达“由什么组成”，依赖图表达“先有谁、后有谁”，验收契约表达“怎样证明做到了”。
本文用同一条训练诊断链路比较五种常用方法：功能树、WBS、FAST 功能分析、能力地图和 Feature Breakdown Structure。核心原则是：先按用户能力和业务价值拆“做什么”，再按架构与代码模块分配“由谁实现”。
导言
需求分析报告是一份开发前的决策合同。它要在投入主要研发资源之前回答五个问题：客户真正需要什么，需求由哪些部分组成，有哪些技术路线，项目是否可行且值得做，以及每条需求究竟如何定义和验收。
即使报告是在功能已经穿刺或实现之后补写，正文也不应从“已经完成了什么”出发。代码、测试和实验只能作为分析者校验接口、约束、技术可行性和估算边界的材料；最终报告仍应冻结在开发决策时点，使用“应、必须、拟采用、计划验证”的语态，不写实现完成率、测试通过情况或上线效果。
本文按六个阶段组织完整方法：识别真实需求、拆解需求组成、调研与选择技术方案、评估可行性/工作量/价值、定义需求与验收、确定优先级并建立基线。每个阶段都明确要消除的不确定性、适用方法、输出物和评审门。
导言
分析数据平台、训练平台、日志系统或指标系统时，常见错误不是“不会画图”，而是用一张图回答了它不擅长的问题。DFD 解释数据经过哪里，IPO 解释一个处理如何变换，数据血缘解释结果从何而来，ER 模型解释事实如何持久化，领域模型解释业务规则由谁维护。本文用同一个训练与指标示例拆解五种方法，并给出组合顺序、优劣边界和落地检查表。
导言
业务讨论中最常见的误区，不是图画得不够漂亮，而是用一张图回答了错误的问题。想确认执行步骤，却画满参与者和消息；想追踪订单状态，却用时序图枚举所有异常；想划分责任，却把普通泳道当作 BPMN 执行语义。
本文用同一个“电商订单履约”案例做受控比较：业务事实不变，只改变观察轴。流程图看步骤，BPMN 看参与者、事件和规则，泳道图看责任与系统，状态机看订单生命周期，时序图看系统调用。读完后，应该先能选择合适的图，再决定用什么工具绘制。
导言
我的长期职业目标可以收束为一句话：理解软件计算逻辑，把它映射到计算、通信、存储和容量受限的硬件上，通过拆分、掩盖、流水和协同设计提高有效利用率；再把这套理解变成可扩展的性能模型、硬件建议与团队分工。
这不是“会调几个 Kernel”或“熟悉某个训练框架”的目标。我要培养的是从工作负载、系统、软件到硬件的完整判断力：知道数据从哪里来、何时产生、在哪里停留、被谁消费、为什么等待，以及增加哪一种资源才真正缩短端到端关键路径。
导言
我曾把一个看起来很明确的任务交给 AI：阅读 verl 代码，参考已有 GRPO 脚本适配 Kimi3 的减层训练，并在 NPU 上跑通第一个强化学习优化步。两天后，AI 仍在换软件版本、调整层数和重跑 OOM。真正棘手的不是“还没成功”，而是我无法回答领导接下来一定会问的问题：卡在哪里、解决过什么、时间花在哪里、还能不能解决、还要多久、代码是否上仓、中文设计文档在哪里？
这促使我把 Goal 从一句终点描述改造成一个工程控制面：用 goal-definition 先与用户签订任务合同，再让每个 Goal 强制携带 goal-execution，按证据等级执行有界循环。最终目标仍然重要，但每一轮都必须留下新的事实、排除一个原因，或形成一个可交付成果。
导言
“模型优化”“框架优化”“算子优化”和“软硬协同”经常出现在同一段讨论里，却不一定在回答同一个问题。本文建立一张七层诊断地图：先确认被控制的对象、真正变化的物理量和最后采用的验收指标，再判断优化属于哪一层。这个分层不是唯一的行业标准，而是一套避免跨层归因错误的工作方法。
导言
最近我对应该长期研究什么技术产生了迷茫。我不喜欢人员管理：每个人的诉求和心思不同，统一理解、共情和换位思考会持续消耗精力。我更希望别人因为我的技术判断、工程能力和解决方案付费。
但“越底层越关键”“越难越值钱”“卖价越高工资越高”都不是可靠规律。AI 应用背后横跨算法、训练系统、推理服务、框架、操作系统、驱动、芯片、封装和晶圆制造；每一层的交易单位、商业模式、资本强度和劳动议价方式完全不同。本文用截至 2026 年 7 月 29 日可公开核验的价格、收入和工资数据，回答两个问题：钱在技术栈中如何流动，以及我应该站在哪个位置积累长期能力。