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

从复杂到庞杂一个老码农用 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 辅助走一遍在真实场景里边学、边想、边干。