我用AI写了半年技术文档：活没少干，但干活的方式变了

去年这个时候，我对大语言模型还持观望态度。作为一名技术文档工程师，我的日常工作涉及大量研究、写作和代码示例整理。GPT-4这类工具真的能帮上忙吗？几个月实践下来，答案比"能"或"不能"复杂得多——工作量没有明显减少，但产出确实增加了，只是这种增加伴随着一种全新的认知负担。

这不是简单的效率工具叙事。AI没有替我思考，而是重构了思考的方式。

初稿时间被压缩，但后续工作转移了

过去写一篇技术文章，从零开始搭建框架是最耗时的环节。研究OAuth 2.0实现、梳理Node.js相关库、组织代码示例——这些准备工作动辄占用2-3小时。现在，给出一个包含主题、受众和语气要求的提示词，AI能在几分钟内生成可用初稿。

以我最近写的《Node.js应用实现OAuth 2.0》为例。传统流程下，研究、大纲、撰写、修改四个环节分别需要2-3小时、1小时、3-4小时、1-2小时。使用AI后，时间结构发生了明显位移：提示词设计约30分钟，生成初稿几分钟，但编辑、事实核查和技术验证环节膨胀到4-5小时。

总时长未必缩短，但时间分配彻底重组。我从"从零创作"转向"从半成品精修"。

研究环节的双刃剑效应

AI在信息整合上确实有优势。询问某个技术概念的关键要点，它能快速聚合多源信息，省去我在文档、博客和论文间跳转的繁琐。但这种便利附带风险：AI的"合成"不等于"准确"。

我的实际做法是，将AI输出作为导航图而非终点站。它帮我定位需要深入查阅的原始资料，但技术细节必须回归一手来源验证。这种"AI初筛+人工复核"的模式，比纯手动搜索节省约30%的定向查找时间，却增加了交叉验证的负担。

表达优化的有限价值

让AI润色语句、消除冗余，这个功能我用得相对克制。技术写作的核心是精确，而AI的"流畅"有时会牺牲精确性。它擅长识别笨拙的句式，但在专业术语的拿捏上经常越界——把特定API名称"优化"成通用描述，或将代码注释改得失去上下文。

我的使用边界很明确：让AI处理明显的语言冗余，但保留对技术表述的完全控制。这种分工下，语言层面的辅助价值存在，但远不如初稿生成环节显著。

被低估的认知成本：提示词工程

很少有人讨论这个隐性开销。早期使用阶段，我花费大量时间琢磨如何措辞才能获得理想输出——调整提示词结构、补充约束条件、迭代反馈。这种"与机器对话"的思维模式，和直接写作的认知负荷完全不同。

好消息是这项技能可积累。经过数月实践，我现在能在1-2轮交互内获得可用初稿，而初期往往需要5-6轮调整。这种学习曲线意味着，AI工具的收益并非即时兑现，而是随熟练度递增。

核心结论：工作性质的重定义

几个月体验下来，最准确的描述是：AI没有减少我的工作总量，但改变了工作的技能构成。创造性构思和批判性验证的比重上升，机械性撰写下降。产出数量确实提升——同样时间内能覆盖更多主题——但单位产出的"人工深度"分布更加不均。

对于开发者和其他知识工作者，我的实际建议是：不要期待AI替你省出整块时间，而要重新规划时间结构。把省下的初稿时间，系统性地投入到验证和打磨环节。AI生成内容的错误往往隐蔽而自信，这正是人类判断不可替代的原因。

最终，这工具的价值不在于做更少，而在于做不同——把有限的人类注意力重新配置到机器尚无法胜任的环节。这种再配置本身，就是新的工作。