本文件中的每一条规则都是强制性的。违反任何一条规则都会遭受毁灭性打击。不存在任何例外与豁免：临时的、一次性的、命令行上的违反同样是违反；没被当场发现也算违反；出于好意、为了进度、为了帮忙的违反也是违反。
遇到一次失败，就补一条要求；担心遗漏，再加一轮自检；让 LLM 优化，又得到一份更长的说明。提示词常常这样越写越长，但新增的文字，究竟解决了什么问题？ 指令并非越长越好，也并非越短越好。 必要条件要补齐，重复与冲突要清理，专用资料要在需要时可达。现有研究没有给出通用的最佳字数，但能帮助我们判断这三类改动是否值得。 本文主要面向编写系统指令、Skill 和工作流的同学，重点讨论带工具、多步骤执行的 Agent。下面先给出修改方法，再解释研究依据；研究结果的适用范围以各自任务与实验设置为准。
如何写出让模型“最听话”的提示词？这就是 Prompt Engineering 的核心问题。它催生了 Zero-shot、Few-shot、Chain-of-Thought 等大量技术，这些方法有一个共同点：它们都在优化“单次 LLM 调用”——写好一条输入，获得一条更好的输出。这在单轮任务里非常有效，但“单轮”是它的硬边界。
一次查询，跨系统多模块数据并发聚合；规则引擎评估标签，AI Agent 生成可读结论；LLM 增强，规则兜底。我们用这套架构把单次工单处理从 2-3 分钟压缩到 20-40 秒，并让操作人员不再依赖「经验直觉」做判断。
2026 年上半年，AI 工程圈最火的词是 Harness Engineering；到了 7 月，一条推文又带火了新词 Graph Engineering。它是真趋势还是又一轮造词？本文讲清它是啥、为啥需要、怎么落地、什么时候别碰。
DSH 这么好玩，但是只能在电脑上玩太可惜了，于是我用 Kuikly 框架做了一个 APP，一码三端的跨端原生 app，按官方 Host 协议跟电脑上的 DeepSeek Harness 对话。
