让AI助手解释一个API、总结一份文档、生成教程大纲，甚至写出代码文章的第一版，只需要几秒钟。那技术写作者还能提供什么？
过去，搭建一个技术写作作品集可以很简单：建个网站，列一串文章，写几句写作经验，再挂上社交账号链接。这套做法现在不够用了。开发者真正需要的，不是有人把端点说明写对，而是有人理解这个端点如何嵌进一个应用里。
拿一条最简单的接口说明举例：POST /api/users。初学者可能会写"这个端点用于创建新用户"。这句话技术上没错，但开发者紧接着会冒出一堆问题：需要什么认证？要带哪些请求头？请求体长什么样？哪些字段必填？校验失败会怎样？成功响应是什么格式？返回哪个状态码？邮箱已存在时怎么办？这个端点幂等吗？在JavaScript或Python里该怎么处理响应？
好的开发者文档要回答这些问题。这靠的不只是写作能力，还需要技术调查能力。也正因如此，这个角色正在从"技术写作者"转向"开发者教育者"——不只是解释技术，而是帮另一个开发者真正把技术用起来。
AI该被当成调查工具，不是代笔
AI确实擅长处理重复性工作：生成初稿大纲、提供替代解释、简化复杂句子、找出可能的边界情况、把笔记转成初稿、生成测试用例、解释陌生语法、审查结构、头脑风暴示例、比较不同方案。
但有一条界线必须划清：AI可以加速思考，不能替代对正确性的责任。如果AI生成了一个Node.js示例，就得把它跑一遍；如果它解释了一个API，就得拿解释去对照API实现或官方文档；如果它建议了一条命令，就得亲手执行；如果它生成了一份教程，就得像读者一样从头到尾跟着做一遍。
这样，AI的角色就从"帮我写这篇文章"变成了"帮我调查、测试、质疑并改进这篇文章"。
你得能做出你教别人做的东西
这可能是给想成为开发者方向技术写作者最重要的一条建议：不必先成为资深软件工程师才能写文档，但你应该能读懂代码、能解释代码。
你需要理解开发流程，足以调查一个代码仓库、安装依赖、运行应用、读懂报错、修改代码、测试示例，并说清楚发生了什么。
- 写React教程，你得熟悉到能判断一个示例是否不完整
- 记录REST API，你得懂HTTP方法、请求头、认证、状态码、JSON载荷和错误处理
- 写GitHub Actions，你得懂工作流、任务、触发器、运行器、密钥和部署步骤
- 记录Python包，你得能把它装上并跑通示例
目标不是什么都懂，而是技术上足够独立，能验证自己写下的内容。作者自己的作品集本身就是一个软件项目：首页直接说明他做什么，整个站点用来展示他如何做开发者教育，而不只是一份在线简历。
这个项目用到的技术栈包括React、TypeScript、TanStack Start、Vite、Tailwind CSS和Lucide React。Vite负责开发与构建流程，Tailwind CSS负责样式，Lucide React提供图标。项目结构上，路由文件、组件、资源文件和配置文件各有分工——组件用来拆分可复用的界面片段，资源文件同样属于文档叙事的一部分，配置文件也不是可有可无的东西。
部署环节用的是Netlify，而Git对技术写作者同样重要。作者还提到，在构建和写文档的过程中会使用AI，而其中最重要的AI技能，是把它当作调查和验证的伙伴，而不是代笔工具。
作品集要证明的是这些能力
如果今天从零开始，作者会这样搭建作品集。而作品集真正的考验在于：它能不能证明你具备调查、验证和把知识转化为可执行文档的能力。
这个项目最终教会作者的一件事是：你不需要成为房间里最好的开发者。但你需要成为那个能把技术讲清楚、并且亲手验证过的人。
热门跟贴