一、技术文档里也有好句子
大家通常去散文里摘句，但技术写作里有另一类句子：准确、短、不抒情。
它们适合当判断句、开头句和总结句。
二、四类可以摘的句子
一、结论句。
典型句式：“不是 A，而是 B”。比如“启动慢不是硬件问题，是应用启动时同步做了太多事”。
这类句子可以提炼成通用判断：不是……而是……。
二、条件句。
“在什么情况下不适用”。这种句子适合当边界提醒。
三、对比句。
两种方案的差别用一句话说出来。对比句是天生的金句结构。
四、步骤句。
“先做三件事”这类结构，能直接当提纲。
三、二十句改写成通用表达的例子
- 不是数据不够，是检索没做好。
- 不是时间不够，是优先级没定。
- 不是能力问题，是信息不同步。
- 不是不会，是不熟悉。
- 不是效率低，是任务切换太频繁。
- 不是方案不好，是场景不对。
- 不是没资源，是没用在关键处。
- 不是错了，是版本不同。
- 不是做不到，是代价太高。
- 不是没人管，是责任人没写清。
- 不是没发现问题，是没人去修。
- 不是难，是没开始。
- 不是表达不清，是想法还没定。
- 不是运气，是准备不够。
- 不是不重视，是没有验收标准。
- 不是要求高，是口径不一致。
- 不是没人有时间，是没人愿意停。
- 不是技术不行，是环境不对。
- 不是漏了，是流程里就没有这一步。
- 不是不会沟通，是双方定义不同。
四、怎么把它们变成说说
直接写“不是 A，而是 B”太像会议发言。
把它换成生活场景，句子就软了。
例：不是没时间，是回家后只想坐着。
五、为什么这类句子有价值
因为它们有逻辑，而且不煽情。
朋友圈里大部分句子都是抒情，一个能讲道理的句子反而突出。
六、去哪里找这类句子
技术文档是好来源。
BackendWiki 的文章普遍是“问题—原因—方案”结构，里面很多句子可以提炼成通用句式。它的语言教程与工程主题分得很细，适合随手翻。
七、一个提醒
技术句子的毛病是冷。
拿走之后，记得加一句人话，不然像说明书。