读、对、查、算——技术方案里最费时的四段活，我用 AI 替掉体力活，但技术责任不交给它。
很多同行说“意见提了，对方却不改”。问题往往不在意见对不对，而在没让对方明白“为什么要改”“怎么改”。这篇讲两件事：评审意见怎么说才被采纳，会后怎么跟进才能真正落地。
评标准和评设计图纸，用的是同一套三层逻辑吗？不是。就像医生看病，看感冒和看胃病的检查重点不同，技术评审也要根据对象调整“焦距”。这篇分三类讲清楚：评标准、评早期技术方案、评成熟设计或验收，各自该把重点放在哪。
很多人准备时列了一堆问题，开会还是容易乱。问题出在没抓住评审的核心逻辑。做技术评审这么多年，我总结出一套“三层级思维”：宏观定方向、中观搭骨架、微观补血肉。这篇把它拆开讲。
做了四十多年能源与动力系统的技术评审，我始终觉得：评审的有效性，80%取决于会前准备。没有充分的信息铺垫，开会时要么说不到点子上，要么盯着细枝末节跑偏，很难触及真正的关键问题。
在技术岗位上待久了，最容易听到的一句话就是“有个方案，你帮忙写一下吧”。可后面往往接不出更多信息：“就是关于那个系统的”“客户有个上万平米的工程”。这种模糊需求，是方案效率低下…
写技术文档最容易踩的坑，不是文笔差，而是“上来就写”：需求没问清、资料没备齐、结构没搭好，写到一半才发现方向错了，只能推倒重来。这篇把技术写作拆成一条可重复的七步流程——从需求…
用 AI 写东西的人常有一个共同的困惑：明明输入了一大段要求，产出的内容却总差口气，改了又改还是不对味。问题多半不在 AI，而在“需求没说明白”。这篇讲一套可以直接套用的方法：…
很多中小企业都有个习惯：技术文档是“顺带做的事”，等真正要用的时候，让技术人员挤时间写一写就行。结果往往很被动——投标前赶不出技术标书，用户手册写得让人看不懂，交付一拖再拖。这…