从复杂到庞杂：一个老码农用 TDD 结合 LLM 的探索心得

一、注释驱动的提示词模板：让 Copilot 生成 80% 的测试代码

作者是一名工龄 20+ 的嵌入式软件工程师，在探索 GitHub Copilot 结合 TDD 的过程中，总结出一套注释型提示词模板。模板结构如下：

// @[Name]: verifyBehivorX_byDoABC
// @[Purpose]: 根据 SPEC 中的哪部分，为何用这种方式验证
// @[Steps]:
//   1) do ..., with ..., as SETUP
//   2) do ..., with ..., as BEHAVIOR
//   3) do ..., with ..., as VERIFY
//   4) do ..., with ..., as CLEANUP
// @[Expect]: 如何验证
// @[Notes]: 参考哪个已有用例
TEST(UT_Category, CaseNN_verifyBehivorX_byDoABC) { ... }

用例命名采用"验证什么结果，通过做什么动作（verifyWhatResult_byDoWhatAction）"的句式，如 verifyPostEventSuccess_byMultiObjectsPostEmergencyFaultEventContinuely。按这个模板写完整注释后，Copilot 能生成约 80% 的测试代码。

关键洞察：在注释里写清当前用例参考了哪部分已有代码，相当于告诉模型"参考答案在哪里"，生成质量会直线上升。

二、两记当头棒喝：讲清楚与想清楚

在探索过程中，课程带来两个核心认知转变：

第一：讲清楚的是不可言说知识，而非显性知识。 显性知识（套用公式）一直很清楚，真正需要提取的是不可言说知识——那些分析、设计、拆解、转换过程中用到的思考步骤。不可言说知识即使直接写出来也无法直接使用，但能以思考或推理步骤的形式呈现，也就是思维链（CoT）。把老警察的办案过程提取为步骤，就是对不可言说知识的提取。团队利用 LLM 提效的关键，正是找到不可言说知识在哪里，将其提取为 CoT，再让 LLM 反复使用。

第二：想清楚是使用 LLM 的前提条件。 Cynefin 认知框架帮助理解了这一点：注释模板之所以有效，是因为写注释的过程本身就是"想清楚"的过程——从复杂（Complex）模式转向庞杂（Complicated）模式，再到清晰（Clear）模式。调试（debug）是复杂模式的典型表现，此时找 LLM 帮忙只会添乱。

三、不同开发阶段对应不同认知模式

用 Cynefin 框架分析软件开发的各个阶段：

需求分析处于复杂模式比较正常——需求并非显而易见，需要探索后才能感知到真正的需求点在哪里。

架构设计处于庞杂模式比较合理——感知到需求后，通过分析寻找合适的方案，拿出架构设计作为响应。如果架构设计阶段还处于复杂模式（“试试再看效果”），说明需求还没想清楚，需要回头审视。

编码实现理想状态是清晰模式——架构设计拆解为任务列表，感知任务项、归类并实现。

**调试（debug）**实际处于复杂模式——打断点（探测）、看运行状态（感知），此时对程序运行没有清晰预期。这解释了为什么 debug 时找 LLM 帮忙效果差。

四、与 LLM 共存的程序员：人有人的好处，机器有机器的用处

一个隐喻：会写代码的程序员遇到会生成代码的 LLM，就像达·芬奇画完蒙娜丽莎，有人扛着摄像机"咔嚓"几张，张张美若天仙。会写代码这件事，未来只是电费问题，不再是研发人员雇佣费问题。

但这并不意味着程序员失去价值。照相机出现后，画家并没有消失，而是转向了摄影无法替代的创造性工作。程序员的价值在于：提取不可言说知识、构造思维链、判断 LLM 生成结果的质量、在复杂模式下探索问题边界。

实践建议：自己下场练起来，手感热起来，才会有真正的启发。只看课程不实践，只会在复杂和庞杂之间徘徊，无法抵达清晰的彼岸。可以从一个具体的软件模块开始，尝试把整个开发流程（需求分析 → 架构设计 → 代码实现 → 测试验证）都用 LLM 辅助走一遍，在真实场景里边学、边想、边干。