// 记录用户个人技术博客写作风格与方法论。用于起草、修改、命名、组织或评审技术文章，尤其适用于前后端工程、调试排查、性能优化、基础设施、AI 辅助开发、群聊开发、发布回滚、真实问题复盘等实操型文章。
| name | technical-writing-style |
| description | 记录用户个人技术博客写作风格与方法论。用于起草、修改、命名、组织或评审技术文章，尤其适用于前后端工程、调试排查、性能优化、基础设施、AI 辅助开发、群聊开发、发布回滚、真实问题复盘等实操型文章。 |
使用这个 skill 时，要写出用户偏好的技术文章：实战、鲜活、有证据、重过程，并且让读者看完之后真的知道怎么做。
标题要优先满足这些特点：
推荐标题模式：
你还在古法编程吗？🦞 把小龙虾接进工作群（一）：先让 AI 看懂前后端背百遍八股，不如一次实操：从带宽打满到首屏优化两月没动的项目突然爆红：一场由 ESLint 配置缺失引发的血案从买服务器到搞定一切：帮朋友搭建企业技术基建（一）我踩了大家都会踩的坑：一次小程序开发复盘避免过于“实现细节中心”的标题：
把代码仓库变成群聊可开发系统Git Subtree 合并前后端仓库实践OpenClaw 接入钉钉机器人教程如果一个标题准确但太像内部技术说明，要改成结果导向：
前后端合仓实践 -> 先让 AI 看懂前后端发布回滚脚本设计 -> 让它敢发测试、能回滚OpenClaw 接入工作群 -> 聊聊天就把活干完文章开头先讲痛点和目的。
前几段要回答：
常用开头方式：
问题不在于项目属于哪种产品形态。具体领域不重要，真正的问题是...背百遍八股不如一次实操。今天朋友请我帮忙搞一下...在此记录全过程。过去两个月没碰这个项目，再次打开突然一片红。这不是为了追求某个概念，而是为了解决一个真实协作问题。今天部署好某工具后发现核心功能没了，于是我开始找平替。这篇文章讨论的不是某个列表怎么做，而是某种体验应该如何落地。首先，要明确几个原则。除非文章就是概念解释，否则不要一上来就写抽象定义。即使要讲理论，也先用真实现象或真实事故把读者拉进来。
优先使用清晰的编号标题：
一、问题现象
二、原因分析
三、方案选择
3.1 方案 A
3.2 方案 B
四、实操过程
五、验证效果
六、截图建议 / 注意事项
七、小结
实操型文章推荐流程：
基础设施教程推荐流程：
排查型文章推荐流程：
体验问题技术化文章推荐流程：
AI 自动化流程文章推荐流程：
我发现、我猜测、我验证、我最后选择。古法编程、擦屁屁、血案、踩坑、爆红。用户过往文章常用“可见证据”推进：Network 面板、依赖分析图、终端输出、配置文件、性能数据、前后对比截图、发布日志等。
写文章时，合适的位置要补“截图建议”：
截图必须提醒打码：
.env文章要同时讲“怎么做”和“为什么这么做”。
不要只罗列命令，要解释：
代码块要可复制，但不要大段堆文件。优先使用短小、聚焦的命令和片段。
常用解释方式：
这个配置的作用是...如果只做到这里，会有一个问题...为了验证这个猜测，我...最终业务代码几乎只需要改...这里不选择方案 B，是因为...当用户要写公开技术博客时：
项目、前端、后端、web-admin、web-mobile、backend/api、服务、工作群。示例：
工作群可以是钉钉、飞书、企业微信或其他 IM 工具，平台不重要，重要的是权限、确认和审计。钉钉机器人实战 作为系列总标题，除非文章专门讲钉钉。当文章由工具变更、商业限制、开源争议、功能移除等事件触发时，可以立场鲜明，但要快速回到实操：
这种写法适合类似“某工具社区版移除核心功能，我来试试平替”的文章。
当文章是证书、服务器、Nginx、对象存储、域名、CI/CD 等基础设施教程时，要把读者当成“跟着做的人”：
当文章来自产品体验问题时，不要只讲代码。先把体验目标说清楚：
再进入实现细节。
当文章讲 AI、Skill、MCP、Agent、ChatOps 时，要先讲流程原则：
不要把 AI 写成万能助手，要写成“有边界、可验证、可回滚的流程执行者”。
当用户基于文章提出反馈时：
这些链接是用户过往文章风格的参考材料。使用本 skill 时，要把它们作为语气、结构和写法偏好的长期参考：
可复用特征：
一、二、三 和 1.1 / 2.1。实测、踩坑、复盘、总结、帮朋友、问题分析、解决方案。