旧的入门建议已经不够
几年前，junior 可以从低风险任务开始：写简单说明、维护 FAQ、整理 release notes、修改已有页面。生成式 AI 首先压缩了这一层工作。初稿、改写、摘要和翻译几分钟就能完成，所以公司越来越少愿意只为“写第一版文字”设置单独岗位。
三年里真正改变了什么
职业没有消失，任务价值发生了变化。生成文本更便宜，但找到可靠信息源、验证产品行为、设计信息架构、保证发布质量仍然困难。企业因此更需要能连接工程、内容和发布流程的人，而不是只负责写段落的人。
数据说明什么
BLS 的 OEWS 数据并没有显示 technical writer 已经崩溃：2019 年约 50,760 人，2024 年约 55,530 人，中间几年大约在 48,000 左右。但 BLS 对 2024–2034 的增长预测只有 1%，并明确指出 AI 提高生产率可能减缓就业增长。更准确的说法是增长很弱、工作内容快速变化。
U.S. technical writers: BLS OEWS employment estimate
Chart source: U.S. Bureau of Labor Statistics, Occupational Employment and Wage Statistics. These are wage-and-salary employment estimates, not a census of everyone doing documentation work.
Junior 工作在哪里减少
最先被自动化的恰好是过去给新人练习的任务：第一版草稿、改写、摘要、FAQ、翻译、简单表格和基础示例。一个资深人员现在可以监督更多输出，因此团队可能减少初级席位，同时把更多责任集中到少数人身上。
什么样的岗位仍然有价值
有价值的角色越来越像 documentation engineering：产品变化、找到事实来源、验证行为、设计结构、生成或撰写、检查 AI、技术评审、自动检查、发布、反馈、再修订。只会写初稿的人最容易被替代；能控制整个循环的人会把 AI 变成工具。
新人现在要证明什么
至少要会 Git、Markdown、docs-as-code 本地构建、HTTP、JSON、状态码、认证和基本 OpenAPI 阅读。还要能实际验证步骤，并能指出 AI 哪句话没有证据。并不要求先成为高级开发者，但必须能够检查自己发布的技术事实。
| Skill | Practical evidence |
|---|---|
| Git | branch, commit, diff, pull request |
| Docs-as-code | Markdown, structure, local build |
| API | HTTP, JSON, auth, basic OpenAPI |
| Verification | reproduce behavior and check facts |
| AI | detect unsupported or invented statements |
作品集应该怎么做
不要只放几篇漂亮文章。做一个完整的小项目：onboarding、一个任务、经过验证的 API 示例、troubleshooting、reference 表格、Git 历史、发布的网站，以及一个 AI 初稿出错后如何验证并修正的案例。作品集应该展示决策过程。
现实的 90 天计划
前 30 天学习技术基础并立即做小成果；中间 30 天完成一个连贯的文档项目；最后 30 天针对真正依赖文档的公司申请，例如 developer tools、API、基础设施、安全、硬件和科学软件。第一份相关工作也可能来自 support、QA 或 developer relations。
现在还值得进入吗
如果目标只是根据现成资料写用户手册，市场确实比以前困难。如果你喜欢理解复杂系统、验证事实、与工程师合作、设计结构和自动化质量，这个职业仍然值得进入。2026 年应该学习的是对“正确、可验证、可维护”的文档负责。
