内容撰写与打磨
从提纲到成稿，把一段模糊的想法写成可以被陌生人读完的段落。改稿时优先动结构，再动句子。
写文字，也整理信息，偶尔写点代码给自己省力气。相信清楚比漂亮更重要，先把事情说明白，再谈语气和手感。
我叫满达，目前常住北京，做的是偏文字与版式方向的工作。日常大部分时间，都花在把零散的信息整理成能读得下去的东西：一段产品说明、一份对外材料、一组需要让人在三分钟内看懂的数据。我不太喜欢堆砌形容词，更愿意先把事实摆清楚，再决定用什么语气说话。
除了写东西，我也自己写前端代码，主要是做小工具，把重复的体力活交给脚本：批量整理文件名、把表格里的杂乱字段统一格式、给长文档做目录检查。这些工具不好看，但省下的时间是真的。久了之后，写和做之间那条界线就淡了——知道实现怎么走，写出来的说明反而更准。
从提纲到成稿，把一段模糊的想法写成可以被陌生人读完的段落。改稿时优先动结构，再动句子。
给材料排层次：什么先出现，什么收进附注。让读者不需要回头找重点，也不用猜哪个数字才是关键。
单文件、纯内联、不依赖外部资源的小页面与小脚本，能离线打开，能在旧机器上跑，交付即用。
确认要解决的问题、边界在哪里、什么时候要。这一轮我通常问得比较多，因为返工最贵的部分几乎都出在这里。
先给骨架：分几块、每块说什么、大概多长。结构对了，后面的措辞才有地方落；结构不对，句子再顺也白搭。
不憋到最后一次性扔出来。写完一段就先给一段，你随时能看到进度，也能随时把方向掰回来。
交付后留一轮冷静期的通读，改掉错别字、口径不一致、数据前后打架的地方，顺手留下版本记录，方便以后再动。
我目前接少量长期与短期合作，更偏好周期清楚、目标具体的事。判断要不要开始，我通常只问两件：这件事值不值得认真做，以及时间够不够用。两个答案都是肯定的，那我们就可以从一次简短的沟通开始。需要核验主体时，可查看页面底部的备案编号。