需求线索从哪里来：搜索、社区与用户反馈

今天先不堆灵感。用三个公开入口，收集一条能继续追问的ClearCopy需求线索，再把“平台要求”“有人遇到的问题”“搜索里的词”分开。成品应像这样：

线索：Apple要求App描述使用纯文本。可观察的任务：开发者需要一段能直接粘贴的介绍。待询问：他们是否真的为清除格式费时，以及是否更担心内容失真。首版候选：默认纯文本结果，不先做富文本编辑器。

这条内容有来源，也有尚未回答的问题。它还不是“市场已经需要ClearCopy”的结论，但已经足够指导一次有具体材料的交流。

从平台原文提取一个确定要完成的动作

打开Apple的版本信息参考，在页面搜索“Description”。配图中请看Description这一行，它把纯文本与长度要求放在同一个字段说明里。本次核对能看到两个直接相关的要求：描述详细介绍功能，限制4000字符，使用纯文本，允许换行而不支持HTML。

拿本书的行李清单App介绍试一遍。把下面这段保存为纯文本：

Create a packing list for each trip, check off items as you pack,
and reuse your lists for future journeys. Works offline.

如果结果里出现<strong>Works offline</strong>或一整段Markdown表格，读者还得自己清理。于是我们有了一个能落到页面上的设计：正文复制按钮只复制纯文本，修改解释放在另一个区域。这里不必先去问一百个人是否“喜欢清爽界面”，平台原文已经说明了一项输出约束。

把这一项记成一行：来源是Apple官方参考；事实是纯文本要求；产品想法是分开复制正文与解释。不要在同一列里写“开发者普遍愿意付费清理格式”，因为来源没有支持这句话。

在社区查到问题后，先判断是不是你要解决的那件事

打开fastlane的GitHub Issues，使用仓库搜索框输入description metadata，也可以尝试localization。逐条看标题和原文，优先找能看见具体材料、操作和结果的帖子。不要只数“description”出现了多少次。

一个实际可核对的历史例子是fastlane issue #6730，它讨论激活多语言时的失败，日志中出现英文和丹麦语的元数据文件。这是2016年前后的历史工具问题，本篇不据此判断现在仍有同一故障，也不把它当成英文润色需求。

这个例子适合练习“排除”：原文的困难在语言配置与发布工具，不在一句英文如何表达。若你因为看见description.txt就把它归为ClearCopy付费线索，做出来的工具很可能帮不上帖主。

你的记录可以这样填：

看到的材料	真正在处理什么	对ClearCopy的处理
Apple纯文本要求	生成结果如何粘贴	保留为输出约束
fastlane历史语言激活问题	发布配置失败	不归为文案润色需求
目标使用者愿意分享的原稿	英文是否清楚且真实	等实际访谈再判断卡点

论坛问题有时会提供非常有价值的原话，但需要保留链接、日期和上下文。不要批量复制作者资料，也别把一条老问题包装成“最近很多人都在抱怨”。若想联系作者，应遵守社区规则，简要说明来意，允许对方不回应。

用搜索词补充表达，不用它代替用户

打开Google Trends Explore。可以先输入app description，再比较app store description。将地区和时间范围设为相同条件，再看工具是否提供足够数据；若不显示曲线，就如实记为本次条件下数据不足，别用自己想象的数字补上。

查询时先分清搜索词与主题，比较时保持地区和时间范围一致。按Google的数据说明，数值经过相对归一化，低量搜索可能显示为0。

还可以在页面相关搜索区域看看出现了什么表达。相关搜索说明区分Top和Rising：一个偏向同一搜索会话中常见的相关词，另一个看相对增长。把找到的候选表达带回搜索结果或访谈中确认含义，别把“增长快”直接换算为购买人数。

为了让第一次操作能完成，你可以采用这个记录格式；下面已填的是本篇实际核对后的结论，而不是伪造的Trends结果：

已核对来源：Apple版本信息参考
确认的要求：Description为纯文本，不支持HTML
社区检查例：fastlane #6730，历史语言激活问题
已排除：把发布配置错误当成英文写作困难
准备查询的词：app description / app store description
搜索量：尚未获取，不填数字
下一次要问：你最近从改写结果粘贴到发布材料时做了哪些清理？

把线索转成一个能当场回答的问题

拿着“是否做了哪些清理”去谈，而不是让对方评价一个功能列表。请他打开允许分享的原稿与最终版，重现复制的过程。如果他直接粘贴就完成，清理格式不是本轮主要问题；如果他删了AI添进去的同步承诺，追问应转向事实核对；如果他只是修了几处语法，就观察通用工具是否已足够。

这样收集下来，即使最后只留下一个小改动，也比十页没有出处的需求清单更有用。本次已经落定的改动是“正文与解释分开，正文按纯文本复制”；至于该不该为英文检查单独建站，留给真实材料与真实使用来回答。下一次打开记录，你可以沿着同一条来源继续核对，不必重新猜自己当时为什么兴奋。