Amazon Quick 上手橙皮书

先决定你用哪个账号

第一次打开Amazon Quick，最容易绕远的一步，是把个人注册和公司部署混在一起。你只是想用自己的账号试一份周报，先走个人入口就够了；已经加入公司的组织，则跟着公司的登录方式走。

本书面向普通订阅用户。你不需要为了读懂后面的例子，先学习云服务器、账号组织或程序开发。先确认身份，再跑一件你明天本来就要做的工作。

1. 个人开始：从官方产品入口进入免费注册（Sign up for free），使用邮箱或页面列出的登录提供方。
2. 公司已有账号：找管理员提供的登录说明，在桌面版选择单点登录（Continue with SSO）。
3. 不要把个人账号里新建的资料当成公司已经授权共享的资料。

邮箱注册怎么走

1. 从https://aws.com/quick进入，确认地址后选择Sign up for free。
2. 填写常用邮箱和显示名，检查邮箱拼写。显示名可能出现在共享资源里，不必填与工作无关的个人信息。
3. 收取邮件验证码。没有收到时先查垃圾邮件，再使用页面允许的重新发送验证码（Resend code）。
4. 按页面要求设置密码，完成账号开通后，选择先用网页或下载桌面版。

这里把按钮写出来，是为了你能认出自己走到哪一步。页面布局可能更新；遇到多出一个确认页，先看它要确认什么，不必为了和教程一样而退回重来。

1. 能进入聊天页，而不只是看到注册成功提示。
2. 退出页面再回来，仍能用同一方式进入同一个账号。

登录页里的Region别急着改

桌面登录页可能同时显示个人登录、公司SSO和Region。个人用户先找Continue with。企业SSO的区域选项服务于公司的配置，不等于你要给自己的每次对话选一个国家。

公司账号能否使用桌面版，还受部署方式与区域支持影响。如果你从管理员那里拿到的是组织登录地址，就把失败页面和选中的区域一起交给管理员，避免自己创建第二个账号。

这次注册实测留下了什么

项目在9月14日尝试自动完成注册，四次没成功，最后由花叔本人在前台完成登录。记录没有证明唯一失败原因，所以这里也不把问题归咎于某个国家、某种邮箱或产品不支持注册。

这个经验对新手更实用的地方是：账号问题先留证据。记下登录方式、卡住的页面、错误提示和时间，就能区分收不到验证码、页面没跳转、登录到了别的账号这几种情况。

我在Amazon Quick注册的第［步骤］卡住。登录方式是［邮箱/页面提供的第三方登录/公司SSO］。页面原文是［粘贴错误提示，删去邮箱、验证码和账号ID］。请只按官方文档解释可能原因，给我一条可验证的下一步，不要连续猜五种设置。

试用与长期可用分开看

本次账号在9月14日开通后，界面给了30天试用；素材在9月16日复核。它说明当时的体验状态，不说明每个用户以后一直获得同样额度。

本书不列定价表。开始任务前，看自己的剩余额度与试用状态；遇到升级提示，先确认任务值不值得继续，再决定是否订阅。不要把「本次没花钱」理解成「任何任务都不会产生费用」。

1. 知道自己正在试用还是已经订阅。
2. 知道从哪里查看会话和月度用量。
3. 没有为了照教程操作而随意开通公司账号或新的付费项目。

从官方入口下载安装

下载这一步只认官方入口。你从搜索结果里找到一个名字相近的安装包，后面再怎么检查权限也不够安心。直接打开官方桌面版下载页面，按电脑平台选择安装包。

1. macOS：从官方页面下载Apple Silicon版本的.dmg，打开后拖入Applications。
2. Windows：从官方页面下载x64版本的.exe，按安装程序提示完成。
3. 安装后从系统应用列表启动，再走上一章对应的账号登录方式。

项目实测用的是macOS桌面版。Windows步骤来自官方入门文档，本项目没有把Windows安装过程当作本人实测。

官方桌面版下载入口：https://aws.amazon.com/quick/download/

先检查电脑能不能装

官方两处系统要求存在差异：桌面入门文档写macOS 12或更新，当前下载页写macOS 13（Ventura）或更新，并注明Windows 10版本1903起。下载和安装以当前下载页及安装包提示为准，不能把较低要求视为统一保证。macOS还需确认Apple Silicon处理器。

如果你不确定电脑芯片，先到系统的「关于本机」查看。不要把「系统版本足够新」当成处理器架构也符合，更不要为了运行一个软件贸然更换电脑。网页入口可以先帮助你确认账号和基础功能。

1. 确认系统版本与处理器架构。
2. 确保磁盘留有余量，尤其是你准备索引大量文件时。
3. 先完成一次登录和小文件任务，再决定是否接入更大的目录。

系统拦截时先核安装包

macOS第一次启动可能弹出来自互联网的应用提示。官方给出的路径是System 设置（Settings）里的Privacy & Security，在Security区域查看对应项目，必要时使用仍要打开（Open Anyway）。

这个动作的前提是安装包确实来自官方。你没有必要为这一本教程关闭系统的整套保护，也不要执行网上看不懂的批量放行命令。先确认下载地址、应用名称和提示指向的是同一个文件。

Windows的SmartScreen也可能要求额外确认。官方文档给了更多信息（More info）与仍要运行（Run anyway）路径，同样先确认文件来源。公司设备受管理策略限制时，应由管理员处理，个人教程不能替代公司规则。

1. 应用来源是官方页面。
2. 只处理这一应用的启动提示。
3. 被公司策略拦住时，没有自行关闭全局保护。

第一次登录后的引导

完成登录后，你会看到Email、Messaging、Local files等数据源引导。看到这么多入口，不必全连。今天要清理一张表，先上传这张表就行；要整理会议，再考虑日历和邮件。

1. 先看当前任务需要哪一份资料。
2. 不需要的分类选择跳过（Dismiss）或界面中的跳过入口。
3. 需要时再从自定义（Customize）→连接器（Connectors）补连接。
4. 如果它要额外权限，读完申请说明再继续。

更新条与失败提示怎么处理

这次实测遇到过桌面版下载更新很慢，旧录屏里一直带着下载条。它是当时的网络与版本状态，不能拿这一次速度去预测所有人的安装时间。

如果主界面可以正常打开，先用一个不重要的任务确认产品可用。若更新阻断使用，就记录当前版本、下载状态和报错。反复重装通常会把登录、缓存、下载这几件事混到一起，反而更难定位。

我能打开Amazon Quick，但更新停在［状态］。当前版本为［界面显示版本］，错误提示为［原文］。请先区分「更新下载慢」和「应用无法使用」，给一项不会删除现有资料的检查。涉及退出登录或清理数据时，先说明会影响什么。

从一份资料开始

给agent越多资料，不一定越接近好结果。第一次练习，我建议只准备一份你看得懂的小文件：一周内容数据、活动报名表，或者一页会议记录。你能自己检查，它的判断才有地方落地。

如果文件里有客户姓名、联系方式、未公开价格，先做一份练习副本。把真实字段替换成样例，不影响你学习流程。遇到数字分析，要保留列含义与单位；姓名可以换，收入和成本的定义不能随便换。

1. 保留原文件，另外做脱敏练习副本。
2. 在文件里写清统计区间和数据单位。
3. 挑出一个自己知道答案的数，留作核对。
4. 把这次希望完成的动作限定为分析或生成新文件。

上传、连接、索引各解决什么

上传适合眼前这次任务：你把一份文件交给它，让它分析。连接适合反复读取某个业务系统：资料还在原来的服务里，它通过连接器访问。索引适合从你授权的一组资料中查找相关内容。

三个动作会在产品里出现在不同入口。不要为了分析一个CSV，先把整个Documents目录都索引进去；也不要以为把某个服务图标打开，就已经给了里面所有文件的权限。

1. 一次性的分析先用附件。
2. 反复用某个服务时再设连接器。
3. 要搜一组资料时再设计目录和索引范围。
4. 每次都能说清：它这次应该读哪份资料，不应该碰什么。

本地文件搬到云上之前

项目截图里，迁移提示写明资料将进入云端以跨设备使用。本地文件夹（Local folders）开关关着时，它还会说明相关知识数据的后续处理。读这些提示比看到一个安全标识就一路继续更有用。

这一页只是解释截图里的同步开关。真正逐文件夹设置全文索引、记忆与agent访问，是后面知识（Knowledge）章节的内容。两个界面不要当成同一个设置页。

第一次交资料时怎么说

这是练习用数据，允许读取和分析。请先确认文件名、行数、列名与统计区间，列出缺失值、重复行和无法理解的字段。暂时不要删除任何行，也不要修改原文件。等口径清楚后，再给出三个最值得处理的问题，每个问题对应原始数据中的具体位置。

这段要求里最有价值的是「先确认」。它让你有机会发现传错文件、月份不同、金额单位不同。模型很擅长在已有材料上往下推，但你交错材料，它也可能认真地把错题做完。

如果产品直接给了结论，就追问它读到的行数和字段。答得上这些，也不等于分析一定正确，不过至少能确认双方在讨论同一份东西。

这一步怎样算完成

资料连上之后，先做一条具体检索。比如找出某天发布的视频标题、某个项目的截止日期，或者一列数据的总数。用你手头的原件对照，能查到并且出处正确，再扩大任务范围。

1. 它列出的文件名与你实际上传的一致。
2. 行数和列名能与原文件对上。
3. 样例数据被明确叫作样例，没有写成真实业务成绩。
4. 它没有悄悄删除缺失行，也没有覆盖原文件。
5. 如果使用连接器，知道怎样暂停或撤销连接。

只看到「已连接」还不够。你要确认的是：这份资料在这次任务里确实能读，读出来的内容也没串到其他项目。

先做一张会前任务单

第一份成果不必选大型看板。我更建议拿一页会议记录做会前任务单：谁负责什么、什么时候交、还缺哪个决定。文字短，容易核对，也最接近日常工作。

你可以用下面的练习材料：团队准备在周五发布一场线上分享；小周负责报名页，小林整理演讲资料，周四前要确认封面；会议里没有明确主持人，也没有确认活动开始时间。全部人物与事项都是模拟案例。

请把这段模拟会议记录整理成会前任务单。分成已确定的工作、待确认的问题和下一次会前检查三部分。没有写明的负责人或时间保留「待确认」，不要自己补。先给我可核对的正文。

先核正文，再要文件

它交出任务单之后，先找两个最容易露出问题的地方：有没有把「周四前确认封面」改成周四发布？有没有给主持人编了一个名字？这两个错误都会让一份看起来很完整的任务单变得不好用。

1. 逐项对照原记录，圈出它新增的事实。
2. 让它删掉无依据的负责人和日期。
3. 确认「待确认」问题仍然保留，没有被美化成已完成。
4. 内容通过后，再要求导出或生成独立文件。

内容可以。请生成一份便于转发的单页HTML任务单，保留待确认项，不要增加事实。文件里的数据、样式都放在自身内部，不依赖外部图片或在线字体。交付后告诉我文件名和可以打开它的位置。

从Library把成果找回来

任务做完，去成果库（Library）找一次成果。这里比一长串聊天记录更适合确认「它到底交了什么」。注意文件名、类型和Owner，不要只看聊天里的完成表情或一句总结。

本项目的仓库流量报告在Library出现，预览能显示正文。文件存在、预览加载、内容正确，仍需要分别检查。

打开文件做一次实际验收

1. 文件能真正打开，正文不是空白。
2. 标题、日期、负责人和待确认事项与原记录一致。
3. 在窄窗口或手机宽度下，正文没有横向跑出屏幕。
4. 如果承诺单文件离线可读，断网后仍能打开主要内容。
5. 下载的文件和聊天里展示的版本一致。

下载成功不代表整个任务已经验收。尤其是网页：看板数字正常、滚动正常、按钮可点，这些都需要实际试一遍。第一件任务不用测试得很复杂，挑出会影响你交给同事使用的那几个点就够了。

记住这一轮怎么做成功的

第一份任务单跑通后，存下原材料、最终文件和那条关键提示词。下次换一份材料重新试，看看哪些要求仍然有效，哪些是这次任务独有的。

不要太早把一长段聊天全部打包成Skill。先让同一方法在两三份相似材料上跑通，再提炼它的输入、步骤和验收标准，后面的Skill章节就是做这件事。

请总结刚才已经成功的方法：需要什么输入、按什么顺序处理、哪些事实不能补写、最后怎样验收。只写能复用的规则，不包含本次模拟人物和具体日期。先给我一版短说明，我确认后再决定是否保存为Skill。

你已经完成了本书最重要的一步：有一件看得见、能打开、可以检查的成果。后面认识更多功能，是为了让这样的任务更稳定、更少反复交代。

把任务写成一份短委托

Chat最常见的问题，往往不在句子不够礼貌，而在你没说要交什么。比如「帮我分析一下」可以得到十几种答案：聊天回复、图表、建议清单、Excel文件，都算分析过了。

任务可以写清四件事：给谁用、用哪份资料、交什么东西、怎样算做好。它们不要求专业术语，你像和同事交代工作一样写就行。差别是，agent不知道你们平时默认的那些背景，需要你补出来。

这份材料给［谁］使用。请只基于［文件或已连接资料］完成［具体成果］。必须保留［关键字段/口径］，不要［越界动作］。交付前检查［两到三个标准］；缺信息先指出，不要补写成事实。

把大任务拆成可核对的两步

要做八页汇报，先确认每页结论；要做数据看板，先确认指标口径；要写一篇文章，先确认三个事实与一个主要判断。你在这些地方看一眼，比全部生成后再改一遍划算。

1. 第一轮只定材料、问题和输出结构。
2. 拿最关键的一条结论与原材料核对。
3. 确认后再生成文件和视觉页面。
4. 返工时指出是哪一处不符合标准，并说明保留什么。

先给我八页汇报的页面清单，每页只写：结论标题、支持这个结论的数据、需要的图。不要先生成整套PPT。我确认结构后，再做文件。

如果任务本来只有一页短文本，就别把它拆成七轮。分步的目的，是让重要错误在便宜的时候暴露。

Fast、Balanced与Smart怎么选

简单改写和格式调整，可以先试Fast；日常写作与汇总可看Balanced；复杂分析再试Smart。用同一份材料比较是否更符合任务标准，别只比较等待时长。响应模式不等于底层具体模型型号。

菜单会随版本和账号变化，以当前实际选项为准。额度也看自己的会话与月度用量，不能把墙上经过的分钟直接当成可计量额度。

追问要指出具体差异

「再好一点」通常只能让它更长、更整齐，却未必更有用。你可以把不满意的位置直接指出来：第三张图时间轴错了；第二页的建议没有数据；这份报告写了文件里不存在的客户名字。

只改下面两处：1）把周同比改为环比，因为原文件只有相邻两周；2）删掉没有来源的行业平均值。保留现在的页面顺序、标题和其他数字。改完列出修改位置，并重新核对总计。

这段话给了修改范围，也保护了已经通过的部分。如果你每轮都让它从头自由发挥，前一轮刚修好的地方也可能被改回去。好结果有一部分来自模型能力，另一部分来自你让它知道哪些决定已经做完了。

对话太长时，存一份当前状态

一个任务讨论很久之后，聊天里会同时存在旧要求、新要求、失败方案和临时数字。这个时候开新对话未必会丢工作，前提是先把当前版本说明存下来。

请为下一轮工作写一份交接：当前目标、已确认结论、最终文件名、必须保留的要求、尚未解决的问题、下一步要验证什么。只保留仍然有效的决定；已经放弃的方案放到最后一行，不要混进当前要求。

新对话先交这份说明和最终文件，再提出本轮修改。你不必把几十屏聊天原样搬过去，真正需要延续的是材料、决定和验收标准。复用材料前，也再看一眼版本日期，避免拿上个月的数据做今天的周报。

Feed先看要不要你做决定

打开活动流（Feed）后，先找需要你回应的条目。你要做的是确认、安排或处理，不必把所有内容都从头读一遍。比如一封邮件已经在别处回复过，就检查这条待办是否仍然需要保留。

项目实测的Feed出现过自动生成的AI简报，证明任务结果可以在这里被看到。不过当天截图里只有那项新闻任务；它不能用来说明邮件和日历都已经完整连接，也不能冒充四个任务同时完成。

重要性和时间顺序不是一回事

官方Feed机制会按与你的相关性组织活动，并区分需要注意和一般信息。它能帮你减少翻找，但重要性判断仍然需要你教：一个平时安静的客户，今天一句很短的催办，可能比一整天频道讨论更紧急。

1. 先点开一条你认为真正重要的活动，确认来源与时间。
2. 看看它提出的下一步是否符合这件事的实际状态。
3. 无关或已处理的条目，用界面提供的反馈处理。
4. 保留需要你拍板的事项，别只为了让页面干净而一键清完。

Feed越用越贴近工作，依赖的是正确资料和反馈。把所有频道都接进来却从来不调整相关性，最终看到的内容未必会更适合你。

Calendar与To-dos怎么一起用

日历（Calendar）帮助你按时间理解安排，待办（To-dos）帮助你追踪要做的事。某件事没有确定日期，先把它留作待办；已经承诺周五交付，则应该同时确认它与日历安排是否冲突。不要让模型替你编一个刚好填满空白的日期。

请检查我明天已授权的日程和待办。把确定会议、可自行安排的工作、需要别人确认的事项分开列。没有明确时间的工作保留待排，不要自动写进日历。发现冲突时说明涉及哪两项，先给调整建议。

这条练习需要你确实连接了对应资料。没有连接日历时，先用一份手工写的模拟安排练习，不能把模型根据惯例猜出的日程当成你的真实明天。

让一份简报少一点噪音

如果你每天都要看新闻或行业变化，给简报规定筛选标准，比规定「一定给我十条」更有价值。数量是上限，相关性才决定它能不能帮你省时间。

请基于过去24小时的公开来源做一份简报。只保留会影响［我的工作/团队决策］的变化，最多5条；每条写发生了什么、为什么与我有关、建议我做什么，并附原始来源。没有足够重要的变化，就少写几条。不要把转载数量当成重要性。

这是一份可用于练习的提示词，不表示本项目每次新闻实测都经过了全部来源核验。你准备对外引用其中的数字或原话时，还得点开那条链接，看它是否真的支持摘要。

Feed这一页怎样验收

1. 能看见活动原来的来源，知道是邮件、日历、消息还是任务结果。
2. 日期与时区符合你自己的工作安排。
3. 简报中每条需要你做的动作都能落到具体事项。
4. 已处理事项没有在下一轮被反复当成新任务。
5. 需要人工批准的动作仍然停在等你处理的状态。

如果Feed一片空白，先判断有没有连接可读的资料、是否有运行过的任务，再检查筛选条件。空白本身可能只是新账号还没有活动；它不自动代表功能损坏。反过来，一页热闹的卡片也不等于工作已完成。

Library先看文件名和类型

成果库（Library）适合找回已经做过的东西。你会在这里看到不同类型的文件和Quick资源。先用名称、类型和归属缩小范围，再打开确认版本，比在几十条对话里寻找下载入口更直接。

如果任务最后应该交PPTX，Library却只有一份HTML预览，就问清楚正式文件在哪里。预览是帮助你看内容的，文件格式则决定同事能不能继续编辑、打印或导入其他工作流程。

Owned by me和Shared with me

我拥有的（Owned by me）表示你拥有的资源，分享给我的（Shared with me）帮助你找到别人分享来的东西。看见这两个标签，就能理解团队协作的入口在哪里；但某张截图没选中共享筛选，不能据此判断共享内容有没有。

1. 找自己的结果时，先切到Owned by me。
2. 找同事交来的内容时，试Shared with me，再按标题搜索。
3. 打开后看资源类型和Owner，确认是不是你要接着编辑的那一个。
4. 普通Library文件共享只给查看权限，需要修改时下载副本再处理；App、Agent、Space分别按自己的角色机制检查。

名字相同的两份文件，可能分别属于不同人，也可能来自不同任务。把Owner和日期一起看，往往能避免「我明明改了，同事却没看到」这种来回。

下载、分享、复制链接分开验

下载让你拿到本地文件；分享给指定人开放资源访问；复制链接只是得到一个地址。对方没有被授权时，拿到Library文件链接也未必能打开。

这份报告我准备交给同事。请先说明当前资源的文件类型、所有者和可用的分享方式。不要替我添加成员或公开发布。告诉我怎样让一个指定收件人获得查看权限，以及对方打开后应该看到哪一个版本。

这个说明适用于Library的资源访问。公开App是另一套发布和访问范围，后面应用（Apps）章节单独解释，不要把「文件链接」和「匿名用户能访问的公开页面」混为一谈。

给文件一个能找回来的名字

「最终版2」「新版最终」很快会让你失去判断。你可以让agent用主题、日期和用途命名，比如「内容周报_20260916_管理层版」。文件名不必复杂，能让下一次的你认出来就够了。

1. 在任务开始时约定成品文件名。
2. 修改内容后，记录本轮改了哪几个事实或页面。
3. 下载副本与Library条目保持可对照的名称。
4. 对外递交前只确定一份当前版，旧版保留在项目里而不继续转发。

本项目就出现过文件名说「报告首屏」，实际截图却是空白的情况。文件名表达的是拍摄者意图，实际文件内容才决定它可不可以用。你自己的团队资料也值得这样看一遍。

下载之后再做三项检查

1. 离线文件能打开，字体和图表没有全部消失。
2. 最终数据与任务里确认的口径一致，尤其是统计区间、总计和单位。
3. 需要编辑的人拿到的是可编辑格式，而不是只有截图的预览。

如果HTML依赖外部图片，换到另一台电脑可能只剩文字；如果Excel只展示了数值却没留下需要的公式，同事接手就要重算。你可以在最初的委托里把这些使用场景讲出来。

请按「同事明天会接着使用」来检查这份成果：哪些内容可编辑，哪些只是静态显示，哪些依赖联网。不要重新设计版面，先列出实际限制，并给出最少的一次修正。

Customize：四个入口各管什么

这四个入口一起看，比孤立背功能名更容易理解。Agent配置（Agents）放角色与任务配置，技能（Skills）放可复用的方法，连接器（Connectors）接工具和服务，知识（Knowledge）管理你允许读取和索引的本地资料。

你要排查一次任务，就按这个顺序问：用的是哪个agent，它加载了什么方法，能调用哪些工具，读到了哪些资料。这样问题会落到一个具体入口上，而不会只剩一句「它怎么不聪明」。

Spaces：按项目整理共享资料

Space适合把某个团队或项目需要的资料集中起来。比如一次活动的介绍、已确认排期、视觉规范和常见问题，放在同一处，后续问答就有了明确范围。

这里展示的是新账号的空状态，不代表我们已经建立并测试了公司共享知识库。你练习时可以先建一个只含公开材料的Space，再检查它的成员、文件和访问范围。公司资料应按组织要求添加。

Space里文件和资源权限不同

把一个已有仪表盘加入Space，并不自动绕过它原来的访问权限；原本无权看的成员，在Space里也未必能看。直接上传到Space的文件则要格外留意，因为能进入该Space的成员可能都能看到这些上传文件。

1. 先列成员，再决定哪些资料适合放进去。
2. 公开练习材料和公司内部资料分开。
3. 分享后请一个实际收件人验证，而不是只看自己的屏幕。
4. 移除资源或成员后，再检查原链接是否还有其他访问路径。

这些属于官方权限机制说明，本项目没有用企业账号逐项跑完。你可以用这张检查表和管理员对齐，再做团队范围内的小试点。

Mission Control：先看Needs input

一个任务没有继续跑，不一定是失败了。它可能正等你批准某次写操作、补一个文件，或者选一个方向。任务控制台（Mission Control）把这些状态集中到一起，适合你同时有几个agent任务时查进展。

1. 从界面右上方的Mission Control入口进入。
2. 先查需要输入（Needs input），打开卡片看它等什么。
3. 再看运行中（Running），区分正在工作和已经结束。
4. 完成项要打开交付文件验收，失败项保留错误信息再处理。

官方也提供agent自身的活动与文件页。你可以从某个agent的页面看它的历史运行，再从Mission Control看全局。不要只看一个统计数字判断所有任务都已经成功。

Settings改动要能说清目的

设置不是越多越专业。先解决明确问题：通知太多就看通知设置；本地资料范围不合适就回文件授权；需要调整默认响应偏好就查看对应选项。每次只改与当前问题有关的一处。

尤其是浏览器与本地工具，某些设置会影响访问范围。你读到需要打开浏览器远程调试时，应先看官方的安全说明，确认自己确实要使用那种模式。没有这个需求就维持原来的工作方式。

我想解决［具体问题］。请告诉我Amazon Quick里对应的设置入口、当前设置会影响什么、改完怎样验证。不要顺手调整其他偏好，也不要以「优化体验」为由打开额外权限。

导入之前，先看这个Skill干什么

Skill把一项任务的方法保存下来：什么时候用、拿什么输入、按什么顺序做、怎样算通过。你导入一个包之前，先读它的说明，确认它解决的是你这次的问题，而不只是名字听起来厉害。

一个Skill可以包含参考文件，也可能依赖工具。写作规范通常只需要文字说明；浏览器操作可能还要本地环境；数据分析脚本则可能引用其他文件。知道它需要什么，才能区分「方法没加载」和「工具没接上」。

1. 查看名称与description，判断适用任务。
2. 检查SKILL.md是否在文件夹根部。
3. 看有没有references、scripts等依赖。
4. 先用没有隐私的材料做一次小测试。

三种导入入口怎么选

已有说明文件或压缩包选2，已有完整目录选3；从自然语言创建方法选1。导入前保留原包，导入后核对正文和参考文件。

1. 进入自定义（Customize）→Skills，选择创建（Create）。
2. 已有.md或.zip时选From file；完整目录时选From folder。
3. 导入后打开详情，检查名称、描述和正文。
4. 如果包里有参考文件，确认详情里也能找到它们。
5. 做一次明确点名的测试，再决定是否用于正式工作。

本项目通过From file导入精简设计Skill；任意压缩包仍需分别验证。

点名调用，先确认加载发生了

本项目最实用的一条经验是：不点名时，设计任务没有自动调用自定义Skill；加上huashu-design名字后，Activity里出现加载记录，随后按方法给出了三个方向。

请使用huashu-design处理这个任务：为运营团队做一页周报看板。先确认Skill已加载，并按其中的工作顺序推进。数据用清楚标注的模拟数据，先给我可比较的设计方向，不要替我选定。

你要找的是实际加载记录或可辨认的行为变化。它在回答里说「我会遵循」还不够。另一方面，没自动调用也不能直接归因为草稿（Draft）状态；这个原因在本项目里没有被证明。

用一个小实验检查方法有没有搬过去

测试Skill时，挑一条很容易看见的规则。比如设计Skill要求先给三个方向；Excel Skill要求先检查数据；报告Skill要求说清局限。你不用一上来检查它所有能力，先确认关键行为发生。

1. 你没有把Skill全部步骤再复制进任务书，否则分不清是Skill起效还是提示词起效。
2. 输入材料与测试目标一致。
3. 失败也保留记录，下一次只改变一个条件。

导入成功后的验收清单

1. 核名称、说明、正文与支持文件。
2. 点名运行小样，确认关键步骤发生。
3. 工具不可用时说清原因，成果打开后再验收。

方法和工具分开检查：方法理解正确但浏览器启动不了时，先排查工具层。

记下导入日期与版本，后续比较才知道规则是否变了。

先把一项重复工作讲清楚

最适合你写的第一份Skill，通常是你每周都会纠正两三次的工作。比如周报总把观看量当成效果；会议纪要总把待确认日期写成确定；报告总省略数据口径。把这些具体纠正写下来，比给agent安排一个夸张身份更有用。

写之前先收两份材料：一份你满意的结果，一份曾经做错的结果。看清它们真正的差别，再把差别变成可检查的规则。你不需要替模型写出每个句子，但需要告诉它什么叫做对。

请根据这两份样例，提炼一份［任务名］工作说明。保留输入条件、步骤顺序、不能补写的事实、最终验收。不要照抄样例中的人名、公司名和数字，也不要加入与本任务无关的方法论。

SKILL.md写到什么程度够用

一个实用的SKILL.md，开头说明名字和适用场景，正文写输入、步骤、边界与验收。把长篇参考材料放在单独文件里，再在正文说明什么时候读它，不必在主文件里塞进整个知识库。

名称：weekly-review
用途：根据已提供的内容数据生成周报。
输入：带统计区间、指标单位的CSV；本周目标。
步骤：先核行列和缺失值，再确认口径，再找异常，最后给建议。
边界：不补造数据，不把浏览量当成新增用户，不覆盖原文件。
验收：总计可复算；每条建议对应数据；限制单独说明。

这是工作说明示例，导入时可让Quick按界面要求整理成Skill文件。你需要检查转换后的正文，确保简洁并没有变成省略关键条件。

description决定它什么时候想起你

description不是宣传语，它要帮助agent识别「这条任务是不是该用这个方法」。写「专业、高效、全面」没有多少区分度；写「处理CSV周报，先核缺失与口径，再给增长与异常结论」会更接近实际任务。

1. 用一句话写清输入类型和要产出的东西。
2. 列出会触发它的自然说法，比如做周报、核对两张表。
3. 说明明显不适合的任务，避免每次问个数字都启动长流程。
4. 用点名调用验证正文，再用自然表达测试能否被发现。

自动发现没有命中时，先检查描述是否过宽或过窄，也看这个Skill是否启用。你可以暂时点名使用，让工作先跑通；路由优化是另一项测试，不必绑着每次任务一起做。

参考文件和脚本别一股脑打包

本项目原设计包约74MB，精简方法文件约1.3MB。体积来自当时实际包，不能视为所有Skill的压缩比例。

按SKILL.md引用保留必要参考、模板与脚本。移除缓存和本地安装依赖；脚本需要的环境仍要另行确认。

1. 不含密钥、真实客户表或私人票据。
2. 相对路径可用，许可保留。
3. 留下的脚本有明确运行条件。

从个人草稿到团队版本

Draft与已发布版本分开，Publish与Share也分开。发布确定版本，分享确定访问对象；当前图中只有草稿菜单，未实际执行发布。

1. 先用Draft跑通小样。
2. 检查变更后Publish，再按界面分享。
3. 让实际接收人用练习材料验证。

企业审批与撤回取决于组织配置，本项目未逐项实测。

先问任务需要什么手段

连接器让agent读取服务、调用工具或执行动作。对你来说最有用的选择方式，是从任务倒推：整理邮件需要邮件来源；更新业务记录需要对应系统；浏览本机文件需要本地授权。

同一个服务能连接，并不说明里面每种动作都已经获准。读一封邮件、生成一封草稿、真正发出去，是不同影响范围的动作。你可以先让它只读或只生成草稿，等工作流程验证过再扩大。

云端、本地与系统工具

云端连接器适合在不同设备上访问已连接服务；本地连接器依赖你的电脑和本地进程；系统工具是Quick本身提供的能力。还有Coding agents入口，用来连接你已经配置好的本地编程工具。

最容易误会的是关机后的行为。云端任务可以继续运行，并不代表它这时还能调用关机电脑上的本地工具。做定时任务时，要把这个依赖写出来，否则任务到时间后可能只完成云端部分。

请检查这个任务依赖哪些工具。把云端可用的连接、需要我电脑在线的本地工具、需要额外授权的写操作分别列出。先检查条件，不要尝试修改业务系统。任何依赖未满足时，说明哪一步会停住。

连接之前看一次权限范围

选择一个连接器后，确认登录的是哪一个服务账号、允许什么动作、资源范围是什么。看到熟悉的服务Logo容易让人直接继续，但你可能同时有个人邮箱和工作邮箱，点错身份之后，后面的结果也会跟着错。

1. 只选择这次任务需要的服务。
2. 在服务授权页面确认账号与权限说明。
3. 回到Quick后做一条无写入的小测试。
4. 检查结果来自预期账号和项目。
5. 找到以后暂停、移除或重新授权的位置。

账号失效、公司策略变化或原服务权限调整，都可能让连接后来不可用。遇到这种情况先查连接状态，不要只重复发送同一句任务指令。

四档授权怎么判断

四个按钮让你决定这次动作的许可范围。第一次跑一个不熟悉的流程，优先看具体请求，再选只覆盖当前需要的方式。不要把始终允许（Always allow）当成「确定」按钮习惯性地点下去。

这张卡片证明本次定时任务创建时出现过人工授权，不表示所有工具的每次读写都会以完全相同方式询问。连接器所有者、用户偏好和组织策略可能一起影响实际行为。

Import MCP之前先看文件

本项目打开MCP导入时，界面能自动检测本机已有工具，并填入配置路径。这很方便，也意味着你要先知道那个配置文件里装了什么。某些工具把服务密钥直接存在配置里，不能因为界面能自动识别就忽略它。

我准备导入一份本地MCP配置。请先说明导入会读取哪些字段、是否包含密钥值、哪些服务会被接入。不要输出密钥原文，不要开始连接。先给我需要检查的字段名称和最小导入范围。

读配置时只看自己的授权文件，分享截图只露字段名。若你无法判断一串值是不是凭证，就先不要把它公开。云端远程MCP和本地MCP是两种部署路径，分别看官方文档和对应权限。

Knowledge从一个文件夹开始

知识（Knowledge）管理的是你授权的本地文件夹与相关索引设置。先给它一个与当前项目直接相关的目录，里面只放确定要使用的资料，通常比把整台电脑都纳入范围更容易检验。

一个可练习的目录可以只包含：项目说明、最近一份周报、已经确认的术语表。你知道里面有什么，后面它回答错了，就能判断是没找到、读错了，还是从别处补了信息。

1. 准备一份脱敏的项目资料目录。
2. 在Knowledge或版本对应的本地文件授权入口添加它。
3. 检查文件夹访问、索引与记忆选项，不把默认值当成已确认的选择。
4. 用一个已知答案的问题验证读取。

三个开关要分别理解

添加文件夹只授予访问，默认不启用索引。全文搜索（Allow full file context for enhanced searching）会上传并索引全文；记住文件信息（Always remember file information）也会上传文件，并从中提取信息建立知识图谱。两项都应先看范围和用量提示。

Agent访问（Agent access）控制这个文件夹的访问，关闭会把该目录从列表移除。不要把关掉记忆理解成已经停止一切读取，也不要把添加目录理解成全文索引已经完成。

本次账号没有已添加文件夹，本页按官方机制说明，不补画不存在的实测界面。操作后用一个已知答案的问题验证；停止访问后，再确认后续任务不再从该目录取资料。

索引范围越清楚，答案越好检查

把正在做的项目与旧归档分开，可以减少过期版本被一起找出来。比如同一份报价有三个版本，文件名和日期又相近，agent很可能需要你明确指定哪一份是当前有效的。

官方提供文件类型、年龄和排除模式等高级设置。新手不必一开始调整所有参数，先通过目录本身限制范围。如果后续要扩大索引，再检查存储和预计用量，确认这批文件值得纳入。

给知识问答留一个答案基准

请只根据我授权的［项目目录］回答：目前确定的活动日期是什么？哪份文件支持这个答案？如果存在两个日期，分别列出文件名与日期，不要替我选。没有找到就明确说没有找到，不要用常识补齐。

测试时，你可以在练习文件里放一句有辨识度、又不涉及隐私的事实。例如「本轮计划只做线上讲座，不安排线下签到」。这类信息不容易靠猜答对，很适合检查它是否读到了正确材料。

不要把这种测试写成恶意指令，也不需要植入秘密。你只是在验证资料检索的准确性，最简单的项目事实就够用了。

它记住了，不等于永远正确

项目状态会变，记忆也需要更新依据。活动延期、负责人更换、旧方案作废，都应该写进当前项目文件。只在聊天里随口提一次，未必足够让后续每个任务都读到。

1. 重要决定落到一份当前状态文档。
2. 新任务明确引用这份文档和版本日期。
3. 发现旧信息被引用时，先定位来源文件。
4. 修改或移除来源后，用同一个问题重新验证。

Knowledge、空间（Spaces）和聊天附件都是上下文来源，但它们的授权与更新路径不同。你不需要背完整架构，先能回答「这句话从哪份资料来的」，就已经能解决很多看似模型能力的问题。

什么时候值得新建Agent

如果一类任务总要反复交代同一份背景、同样的权限和交付方式，就可以考虑单独配置一个agent。比如每周内容复盘、会前准备、项目资料问答。偶尔一次的短问题，直接在Chat里处理就行。

Agent配置承载任务定位、指令和可用资料，Skill承载具体方法。一个负责内容周报的agent，可以用Excel方法核数据，再用报告方法整理结论；没必要为每个按钮都新建一个角色。

我想创建一个内容周报agent。它只处理我明确提供的周度数据，先确认口径再分析，交付一页结论与可复算表。没有授权时不发布、不发消息、不修改原文件。先给我配置草稿，包括名称、适用任务、所需资料和工具。

先检查Name、Description和Instructions

1. 从Customize→Agents→Create创建草稿。
2. 检查名称、描述、指令与权限范围。
3. 用练习输入试跑，通过后再考虑Publish。

专用Agent的Instructions与Capabilities按官方文档配置；共享需先发布并明确授权，创建草稿不等于所有同事已可使用。

Capabilities按需要开

系统默认Quick与自建Agent不能混用。自建Agent的能力配置（Capabilities）按官方文档控制搜索、Skills、Spaces与Connections；读者可以从前页Create开始，而不用在默认Quick里寻找不存在的编辑入口。

创建这个专用Agent时，请只保留完成周报必须的资料与工具。先列用途、输入和可用能力，我确认后再保存。资料不足先指出，不自行扩大到其他文件夹或团队空间。

如果限定具体Skills，检查接力需要的方法是否都在允许范围。默认Quick的Settings画面不能证明自建Agent配置已完成。

运行状态比角色名字更重要

一个agent叫「专家」没有证明作用。运行时，看它加载了什么、用了哪份资料、有没有等你输入、交出的文件能否打开。你可以从它自己的活动页查看，也可以到任务控制台（Mission Control）集中检查。

1. 输入与当前角色的任务范围一致。
2. 需要输入（Needs input）里等待的问题确实需要人决定。
3. 已完成（Completed）之后能找到本次产出的文件。
4. 失败（Failed）或已中断（Interrupted）保留原因，下一轮不把它当成已完成。
5. 重复运行不会偷偷修改此前确认过的材料。

一开始只让一个角色处理一类稳定工作。角色太多会让你花时间寻找该找谁，而不是减少交代次数。等重复任务的边界变清楚，再拆分会更自然。

把Agent交给同事之前

官方机制要求agent先发布才能分享，定时运行也使用发布版本。你在草稿里修好了方法，同事或routine仍可能运行旧版。因此团队使用时，需要把版本当成工作交接的一部分。

1. 写一条短发布说明：修正了哪条方法或增加了什么资料。
2. 检查所需底层资料是否也已向接收人开放。
3. 分享给一个试用成员，用同一份练习输入验证。
4. 让对方报告自己看到的版本与可访问来源。
5. 确认通过后，再按组织流程扩大范围。

Agent共享不会替代底层资料权限。你自己的账号能读某份文件，不代表每个收件人也能读。让实际接收人试一次，能很快发现这种权限差异。

定时之前，先手动成功一次

适合设成routine的，是输入来源稳定、标准清楚、失败可发现的重复任务。每天行业简报、每周数据整理都可以练；需要现场判断、经常缺关键资料的工作，先别急着无人值守。

我建议先手动跑通一次，把提示词和验收标准稳定下来。定时只改变什么时候开始，不会自动修复一个原来就不知道查什么、交什么的任务。

请先试跑这项工作：从过去24小时的公开原始来源中，找最多5条与［主题］相关的变化，附来源和时间。没有足够重要的内容就少写。只生成简报，不对外发送。完成后列出下一次自动运行还缺哪些条件。

写清时间、时区和结果位置

把频率、时区、输出位置和无变化时怎么办写清楚。7:30只是显示时间，还要核实际时区与下一次运行时间。

为已验证的方法创建定时任务：工作日北京时间07:30，统计前24小时，交付中文简报。没有重大变化就说明。创建前展示完整配置与工具权限。

看到授权卡片，读具体动作

从routine详情的Uses进入工具权限，按动作核可用范围。只读检查、写入待办和真实日历连接分别处理；不要看到Calendar一词就推断私人日程已经开放或关闭。

创建这项routine前，请展示实际使用的工具与权限，逐项解释读写对象。只授予任务必要的动作，不因为要自动运行就把所有写权限设为始终允许。

电脑关了，哪些步骤仍能跑

官方routine在云端运行，电脑合上或离线时可以继续执行云端部分。不过一项任务如果依赖本机文件、浏览器或本地连接器，仍然需要相应设备与环境可用。自动任务设计时，把这条依赖提前检查出来。

请检查这项routine是否完全依赖云端可访问的资料和工具。列出每个本地依赖。如果我电脑关闭，哪些步骤不能完成？不要把不能执行的步骤标成已完成，也不要未经允许把本地私密资料同步到云端来绕过限制。

四个任务错开时间，只能减少同时启动的复杂度，并不保证前一个刚好完成。任务之间有依赖时，要明确「前一步成功并产出文件」才继续，而不是只约定相隔十分钟。

用第一次运行校验定时设置

1. 核启用状态、下一次时间与时区。
2. 运行后打开成果，查统计区间。
3. 失败或待输入不能当作完成。

这张图只证明已有的一项新闻routine，不能反推四个任务都已在历史早晨完成。

1. 知道暂停、查错和取成果的入口。

把调研问题缩到能验证

「研究一下AI行业」通常会得到一大段看起来什么都涉及的文字。你如果明天要做选题，更有用的问题是：过去一天有哪些变化，会影响哪类用户，哪一条值得亲自测试。先把使用目的写清楚。

我要为［目标读者］准备三个选题。请研究过去24小时［明确领域］的新变化，优先官方发布、文档和原始研究。每个候选写：发生了什么、与读者的关系、可验证的独特点、我还需要亲自测试什么。不要按热搜声量自动排序。

这份任务里，「三个」是交付上限，不是事实数量要求。只有一个值得写，就写一个；资料不足时留空，比把旧新闻包装成新变化更有价值。

让结论跟着来源走

一个回答有很多链接，并不意味着每句话都有依据。检查时，先从最重要的数字和引语开始。点开对应来源，看它是不是在谈同一个版本、同一个地区、同一种账号，而不是只沾了几个关键词。

1. 把结论拆成可以单独核验的事实句。
2. 为每句找到直接支持它的来源。
3. 记录页面日期与事件日期，两者不同要说明。
4. 找不到原话时改为概述，仍查不到就标未验证。

本项目早期测试遇到过一段无法在对应官方页面复现的引文。我们没有把它当成产品事实继续传播。你不必对每段普通说明逐字核查，但对支撑主要结论的那几句话要认真。

明确事实、推断和建议

请把当前调研结果分成三类：已找到一手来源的事实；根据事实做出的推断；建议我采取的行动。事实后附直链，推断说明依赖的前提。不要把「可能」删成确定结论，不要为了语气更有力而补充未经核查的用户数或性能。

你写文章或向团队汇报时，不需要在每句后面贴一个标签，但自己应当知道各句属于哪一类。产品支持某种工具是事实；它会让某个岗位省时间是推断；建议先在一个小任务里试点，是你基于目标做出的选择。

三者都可以有价值。问题发生在它们被悄悄混到一起，最后读者误以为一句建议已经被实验验证。

长调研先定结构，再补材料

一个较长的研究任务，先给出问题框架，能减少半途跑偏。比如你要评估一款办公产品，就围绕当前任务、资料来源、可交付格式、权限与失败处理来查，不必先收集几十页市场宣传。

1. 写下必须回答的三到五个问题。
2. 给每个问题设一个能接受的证据标准。
3. 先交第一轮结果，暴露缺口。
4. 针对缺口补查，保留原始链接。
5. 最后才组织成报告或演示稿。

先不要写最终报告。请给我研究框架与证据清单：每个问题要找什么一手资料、目前已有什么、还缺什么。确认框架后逐项补齐。对无法访问的来源，写清访问失败，别只凭标题概括全文。

把调研转成一项真实工作

调研最容易结束在「了解了很多」。你可以给它一个接下来的用途：选一个能拍视频的测试、做一页决策备忘录、列一份产品验证清单。这样材料就会围绕行动收拢。

从这份调研里挑一个最值得亲自测试的任务。给我输入材料、实际操作、预期结果和失败判据。只设计我今天能完成的验证，不需要大规模部署。告诉我结果出现A或B时，原来的判断分别该怎样调整。

1. 测试直接回答调研中的关键疑问。
2. 成功与失败都能被记录。
3. 没有把未做的测试写成亲身体验。
4. 最终稿使用的是核查后的结论，不是最初猜测。

先做一个边界清楚的小应用

应用（Apps）适合把一个明确需求做成能直接交互的页面。第一次可以做阅读器、活动说明页或简单计算工具。先明确用户要做的一个动作，再决定它需要哪些数据，通常比一句「做个完整平台」更容易交付。

请在Apps里做一个中文资料阅读页。左边是章节目录，右边是正文，支持切换章节和调节字号。先接入我提供的两章真实内容，其余目录显示待补，不编正文。所有图片内嵌，不依赖外部图片服务；不收集邮箱，不接业务连接器。

这是本项目阅读页采用的方向。它首先要保证内容能读、章节能切换，后面再逐批接入完整书稿。

在预览里实际点一遍

1. 在预览里点击目录、页码和搜索，核对显示内容。
2. 切换到手机宽度，确认导航不遮正文。
3. 只修具体失败动作，再按同一路径复测。

界面变化后，按钮和内容都要实际检查。颜色变了不等于数据接通，首章正常也不代表末章完整。

只修章节切换：第二章显示全文，返回后能再打开首章。实际检查这三步，报告通过与失败。

内容分批接入，先保可读

本项目把全书拆成逐章内容，图片压缩后内嵌。官方限制的是Apps内置存储的单项值不超过350KB，并非整本书或整个应用的大小上限。本项目把每份章节内容控制在300KB以内，为结构和编码留出余量。

对普通使用者而言，不必理解每段代码。你可以直接要求它说明内容怎么存、每次更新哪一章、失败后怎样知道哪批没进。长文导入最怕的是前几章正常，后半本悄悄没了。

1. 目录章数与实际接入章数相符。
2. 每章第一段和最后一段都能查到。
3. 没有用「敬请期待」冒充完整正文。
4. 中文与图片在目标设备上可读。
5. 导入失败能定位到一章，不用重建整个App。

Publish与Share分别检查

编辑版本、发布版本和访问范围分开。预览修改后，需重新Publish才影响使用者；Share控制谁能访问。图中应用尚未发布，只能添加共同管理人。

Public是否可选受账号与功能限制影响。公开App不能带文档限制的内部集成，例如action connectors和Spaces。先核内容与权限，再操作发布。

1. 先核内容、当前发布版本与访问范围。
2. 用实际收件人或未登录窗口验证对应访问。

链接发出去之前最后查什么

1. 使用目标收件人的访问方式验证页面。
2. 确认内容与图片适合公开，链接对应当前发布版。
3. 找到撤销访问入口；若有AI调用，确认额度承担方。

本项目没有验证30天试用结束后这个公开链接能维持多久，因此书里不作长期可用保证。需要长期保存的内容，应保留独立文件和可重新发布的源稿，避免唯一副本只在一个在线页面里。

公开发布是对外动作，正式工作中应在内容与权限确认后执行。本书讲的是操作机制，不代表跟着练习就应该把真实公司资料立即公开。

huashu-design：先比较真实初稿

huashu-design用于HTML视觉设计。本项目用它做运营周报时，先要求共用一套模拟数据，再给不同设计方向。这样比较的是信息呈现方式，不会一边换版式、一边又换数字，最后不知道自己喜欢哪部分。

用huashu-design做运营周报网页。先给三个可打开的方向，全部使用同一份明确标注的模拟数据。共同保留统计区间、六个核心指标、七天趋势和下一步建议。先等我选方向，再深化，不提前替我决定。

第一轮看层级和阅读顺序，第二轮才检查边距、颜色与细节。不要把三个名字不同但布局相同的页面，当成三个真正可比较的方向。

同一份数据，为什么要看三种排法

看板适合让人快速扫指标：本周怎样、哪里异常、下一步先处理什么。面对同一份数字，你可以检查它有没有让重要结论先被看到，还是把每张卡都做得同样醒目。

深色并不自动更专业。手机阅读、投屏、打印、团队每天盯着看，会带来不同要求。你选方向时最好说使用场景，比如「主要在周会上投屏」，这样下一轮调整能围绕读者做决定。

1. 每个数字有单位和时间区间。
2. 颜色有清楚含义，变化方向没有写反。
3. 没有因为追求满屏而加入未经确认的指标。

huashu-excel：先体检，再判断

huashu-excel适合表格清洗、口径确认、指标计算和对账。本项目给它74个仓库的14天流量CSV，先保留一份自己可以复算的基准，再看它怎样判断。

用huashu-excel分析附件。先给体检结果：行数、字段、缺失、重复、单位和时间区间。不要急着分类，也不要删除异常行。再提出判断「真的有人使用」「只是阅读」「疑似重复拉取」需要哪些信号。每项信号写出计算方式与解释边界。

你不需要懂它写的全部代码，但应该知道输入几行、算的是什么、哪个数可以拿计算器复核。否则再漂亮的报告也很难追问。

三个信号各自回答一个问题

以上是同一张真实表格的三处放大，不改写UI。阈值属于本次数据分析，换成订单、观看或活跃用户时，应按新的数据生成方式重新制定。

11.15这个数怎样亲手验

你用计算器算26863除以2409，会得到约11.1511。这个小检查能确认表内公式没有错，但不能直接证明每次拉取是谁完成的。「疑似机器反复拉取」仍然是根据指标作出的判断，需要更多证据才能确认来源。

把这套方法带到自己的工作里：选一个总计、一个比例、一个异常样本，先复核这三样。任何一项不对，就回到口径和原数据，别靠修改图表标签把错误遮过去。

请解释11.15的分子、分母、统计区间和四舍五入方式。再列出这个指标不能回答的问题。不要把疑似自动化行为改写成已经确认的真实用户身份。

huashu-report从什么地方接手

huashu-report适合把已经有依据的发现，组织成可以交给别人阅读的报告。它接手时最需要的输入，是数据口径、已核验结论、读者和报告用途。只给一堆聊天记录，它就要先猜哪些结论已经确认。

请用huashu-report整理这次分析。读者是负责下一周资源安排的团队，报告回答「先处理什么、依据是什么、还缺什么证据」。已有数字见附件，先检查上一步分类的边界，再写报告。没有完成的验证必须说明，不把推断写成定论。

让它回头质疑上一轮结果

项目里，report没有直接把Excel分类复制成漂亮文字。它注意到一个仓库贡献了约28%的浏览，要求再次确认它为什么被分到使用类。这个动作很有价值：漂亮排版之前，还能检查结论是否站得住。

你也可以明确提出这种要求。尤其是上游结果来自另一轮AI分析，应该把关键分类、边界样本和异常值一起交给报告作者，而不只是交一份已经删干净的结论摘要。

写报告前先找三处最值得怀疑的地方：分类边界、单个异常样本、统计口径。每处说明如果判断错了，会改变哪条结论。请用原始数据复查；查不到证据就保留局限，不需要为了完成报告把疑问消掉。

报告里的图要回答具体问题

报告不需要每页都有图。比较不同项目，用可对照的条形图；观察时间变化，用清楚标记日期的趋势；只想强调一个已确认的数，一句话可能比仪表盘更直接。

图下面的说明应告诉读者怎样理解它，别把坐标上的文字重新念一遍。比如「周日下降是否受统计未结束影响」就比「周日数据下降」更有用，因为它提示接下来需要核查的条件。

1. 图的标题是一句可以验证的结论。
2. 单位、样本和时间区间在图附近。
3. 正文没有给图表赋予数据无法支持的因果解释。

没有完成的验证，也写进交付

这段话的价值，在于它明确指出哪道检查还没完成。生成文件、程序化检查、逐页目视检查，是不同工作。前两项通过，不自动等于第三项也通过。

如果你看到这种说明，接下来就把那三张图打开看一遍，而不是只截下它的诚实表态。局限说明的用途是指导下一步补验收，不能代替验收本身。你也可以要求它把未完成项与报告位置对应起来。

交付前请列出实际完成的检查、没完成的检查，以及它们分别影响哪个结论或页面。没有做过的动作不要用「已验证」描述。

给同事看的报告怎样收尾

一份可用报告的最后一页，应该让接收人知道接下来该做什么。你可以按影响和证据强弱排序，先处理结论明确、代价较小的动作；需要进一步取证的事项，写清谁来查、查什么。

1. 把结论压成读者能复述的三句话。
2. 每句后面留下关键依据与文件位置。
3. 建议对应到具体动作，不只写「持续优化」。
4. 把未解决问题移到明确的待验证项。
5. 导出后打开实际文件，核页数、图表和最后一页。

如果报告只是在不断展示复杂度，你可以要求删掉与决策无关的材料，放进附录。删减不是降低专业度，它让读者更容易找到应该承担责任的判断。

huashu-chrome：先确认浏览器条件

huashu-chrome记录的是浏览器操作方法和本地工具用法。把它导入Quick，不代表本机已经自动装好了它依赖的所有桥接程序、浏览器配置和脚本。你要先区分方法被读到了，还是工具真的连上了。

使用huashu-chrome处理这个浏览器任务之前，请先检查依赖：需要哪个本地工具、浏览器是否可用、能否读取当前页面。只做只读检查，不点击发布或发送按钮。缺少条件时说明缺哪一项，不要声称已经完成网页操作。

本项目确实观察到Quick自动加载这个Skill并尝试继续工作。它能说明方法之间发生了接力，但对于截图验证最终有没有成功，仍然要看实际文件和执行结果。

两个Skill接力的真实一屏

这一屏里，前一个设计任务提出需要截图检查，随后加载了浏览器方法。这说明你的一套工作方式可以包含多个方法，而不一定每次都由你手工逐个点名。

也要看到它的边界：加载记录只是执行链的一环。后续还有工具可用性、页面能否打开、截图有没有真的生成等条件。面对自己的流程，你可以把每一环需要留下的成果写出来，让接力不是靠一串绿色勾选来判断。

1. 上一环的输出能交给下一环。
2. 每一环都知道成功产物是什么。
3. 某一环失败时，最后交付会保留这个缺口。

dukou：文稿搬运先用测试内容

dukou用于本地稿件与支持的网页编辑器之间搬运内容，也包含抓取已授权网页正文的工作方式。它依赖相应本地桥接与浏览器插件，不能只靠导入一段SKILL.md就保证所有平台都可操作。

第一次尝试，用一篇不含隐私、三段文字加一张公开图片的测试稿。你的目标是验证标题、段落、图片和顺序是否保留，不要一开始就拿已经定稿的长文章直接发到正式账号。

请先检查dukou的必要依赖是否存在，再用测试稿做一次导入预览。只填充编辑页或保存本地结果，不提交、不发布。检查标题、图片数量、段落顺序和末段是否完整；出现登录或权限问题时，停在该步骤并说明。

搬运前后用四个锚点对照

长文搬运最常见的问题不一定是完全失败，而是少了一张图、最后一段丢了、标题进了正文。你可以预先选四个锚点：首段、一个中间小标题、一张图、末段。导入后逐个对照，能很快发现截断。

1. 保留本地原稿与配图清单。
2. 确认目标账号、目标文档或编辑页。
3. 执行导入后先看预览，不马上发布。
4. 核对首、中、图、尾四个锚点。
5. 如果发生修改，再保存一份对应版本，避免两边内容逐渐分叉。

这套方法同样适用于把本书章节导入阅读App。你不需要把每页从头重读，却需要知道有没有完整抵达另一端。

怎么判断迁移的边界

1. Skill说明被完整读取，是第一层。
2. 依赖文件可以访问，是第二层。
3. 工具成功启动并得到结果，是第三层。
4. 结果与原任务相符，是第四层。
5. 外部页面或收件人实际可用，是第五层。

这几层里任何一层失败，后面都不能自动算成功。你可以只迁移方法，另外使用Quick已有工具实现相同动作；也可以保留原本的本地工具链，但这需要满足它的运行条件。

本书介绍这两个Skill，是帮助你理解方法和工具怎样协作，不把它们包装成安装即通的万能包。它们本地副本未找到独立LICENSE文件，公开分发前还应确认对应发布版本的许可，不能套用其他Skill的MIT说明。

aihot：让新闻任务有明确入口

aihot用于查询中文AI资讯与精选。它带来的价值，是给一类反复发生的资料任务规定入口、字段和处理方式。读者仍然要区分资讯平台的整理与新闻事件本身的一手来源，不能把精选标签当成事实已经核准。

用aihot查询最近的AI资讯，给我最多三个与普通产品使用者有关的选题。每个选题附事件来源、发布时间、我能亲自验证的功能，以及尚未核查的数字。暂时不要写整篇文章，也不要按传播热度直接决定哪个最好。

本项目确认aihot已导入，但没有把它在Quick里的完整新闻选题流程作为已验收案例。你可以按这条提示词开始小试，先检查能不能取得真实数据，再做成定时任务。

huashu-tech：事务方法不等于公司资料

huashu-tech用于公司事务中的信息与流程整理。类似方法可帮助你准备开票材料清单、核对结算步骤、整理合同归档，但真正的公司账号、税务信息和票据不应该随一个通用工具包公开散发。

请只根据我提供的脱敏材料，整理这次结算需要的文件清单、已具备项和缺失项。不要编公司抬头、税号、账户或金额，不要代发邮件，不要提交申请。缺少资料时写明由谁补充。

本项目只确认这一Skill导入与描述保留，没有在Quick中完成真实开票或财税申报。因此这页给的是练习方法，不是已经跑通的商业办理承诺。涉及财务操作时仍需按公司实际流程核对。

huashu-perspective：先把问题收窄

huashu-perspective保存花叔在独立开发、内容创作和使用AI做项目方面的表达与判断材料。它适合帮助你换一种看问题的方式，但不能把生成答案当成花叔本人对你这件事作出的实时承诺。

用huashu-perspective看这个问题：［具体项目情况］。请给出判断依据、最值得先验证的假设和一个今天能做的小动作。只引用材料里确有依据的经历；找不到相关案例就直接说明，不要替花叔编故事。

你使用任何人物视角方法时，都值得保留这条限制。视角能帮助你想到被忽略的问题，最后选择仍然要回到当前材料。尤其是涉及成本、用户和业务阶段，不同项目的事实不能直接互换。

八个Skill怎么按工作选

做看板时，先用excel把指标算明白，再让design做页面；做正式报告时，把数据与已确认口径交给report。涉及真实浏览器操作时，再检查chrome与dukou需要的工具条件。新闻资料、公司事务和项目判断，则分别看aihot、tech与perspective是否适合。

这个顺序不是要求你每次都调用八个Skill。它们各有适用范围，你只取眼前需要的一个或两个。一个小任务如果被十几条流程包围，往往会增加你等待和检查的负担。

请根据当前任务，在已安装的Skill中选择最少的一组，说明每个负责哪一步。不要为了用工具而增加步骤。没有适合的方法时直接说明，仍按任务要求交付；依赖工具缺失时不要伪造执行记录。

分享工具包前，看许可与依赖

本次本地核验，huashu-design、huashu-excel、huashu-report和aihot带有MIT LICENSE；其余四个本地目录未找到独立许可文件。不能因为它们属于同一个工具包，就把所有内容都自动视为同一种授权。

MIT许可通常允许按许可条件使用、修改和分发，需要保留原许可与版权说明。包内另外引用的第三方素材、账号服务和商业数据，还要分别遵守自己的规则。公开分享前看实际下载包中的LICENSE，别只听视频里一句概括。

1. 保留实际随包的许可文件。
2. 移除本地密钥、私人公司材料和用户数据。
3. 列出需要额外安装或授权的工具。
4. 标明哪些已在Quick实跑，哪些只完成导入。
5. 收件人拿到后先用练习材料验证。

先说清楚「失败」发生在哪

遇到问题时，把它压成一句可复现的描述：我在什么入口，用什么材料，执行什么动作，本来希望得到什么，实际发生了什么。只写「不好用」，无论给agent还是给客服，都很难直接找到下一步。

我在［入口］用［文件类型与脱敏样例］执行［动作］，预期是［可见结果］，实际是［现象/错误原文］。请先定位属于账号、材料读取、Skill加载、工具执行、文件生成、展示或权限哪一层。先给最小检查，不要同时修改多处。

错误截图要保留提示和必要上下文，同时去掉邮箱、账号ID、密钥和私人路径。你不必提供所有日志，先给足能区分问题类型的那一小段。若后面需要更多，再逐项补充。

材料没读到时怎么办

它找不到附件，先检查上传是否真正完成；它读到的是旧版本，先检查文件名和日期；它只能给泛泛建议，先让它列出实际读到的字段和来源。这些问题都不需要立刻重写整份任务。

1. 确认当前聊天关联的文件或Space。
2. 让它复述文件名、行数或章节标题。
3. 用一个你知道答案的细节测试。
4. 若权限不足，回到连接或共享设置检查。
5. 换了一份文件之后，明确说哪份取代哪份。

如果文件太大或格式复杂，你可以抽一小段有代表性的内容做测试，但要明确这是样本。它基于样本算出的结果，不能直接当成全量业务结论。保留样本选择方法，才能知道结果适用于什么范围。

Skill没有自动出现时怎么办

本项目已经见过不点名时没有命中自定义方法的情况。排查顺序可以很简单：先确认已经导入和启用，再直接写Skill名字，看是否出现加载记录，最后才调整描述和触发条件。

这次请明确使用［Skill名］。先确认它是否存在且启用，说明加载到的用途与关键步骤。不要重新编造同名方法。如果找不到，请告诉我应该在哪个界面检查导入状态。加载后只运行一个小样任务。

点名后成功，说明方法与任务之间至少能通过显式调用接通。自动发现是否稳定，需要另外设计几种自然表达去测试。你不必把这两项结论混成「全部兼容」或「完全不支持」。

页面白屏，先分文件与展示

遇到白屏，先区分文件没有生成，还是文件存在但预览没有加载。接着检查数据与资源是否完整。只换一个外观相似的页面，不能证明原问题已经解决。

1. 查看成果库（Library）或Agent文件（Agent Files）中是否有实际文件。
2. 尝试重新打开对应版本，保留错误提示。
3. 检查是否依赖外部图片、字体或网络数据。
4. 检查是否只有一个页面空白，还是全部页面都失败。
5. 修好之后用原来同一个动作复测。

请检查这个页面白屏的原因。先确认主文件、数据和资源是否完整，再定位加载错误。不要凭空重做一个外观相似的页面；保留已确认内容，修正后给实际可打开的文件。

别让修复变成无限重来

连续几轮修复没有进展时，应该换的是排查方法。把最后一次有效版本留住，列出这次只改哪一项，确认结果是否改善。否则每次重做都会带来新变量，你很难知道哪里真正变好了。

1. 保留一个能工作的基线文件。
2. 每轮只有一个明确的修复目标。
3. 修完检查原问题，也看邻近内容有没有被误改。
4. 依赖缺失时先补依赖，不靠改文案掩盖。
5. 遇到账号权限限制时，停止在可说明的边界。

如果最后无法完成某个高级导出，就交代已经完成的内容和可用替代格式。你可以接受范围更小但真实可用的结果，不必为了一个「全部完成」的标签丢掉问题记录。

把权限理解成具体动作

安全设置最有用的读法，是从动作看影响。读取一份公开说明、修改本地文件、写入业务系统、给外部收件人发消息，范围逐步变大。你应当能指出当前授权对应的是哪一步，而不是只看一个总开关。

在执行之前，请列出要读取、创建、修改、发送或公开的对象。对每个对象说明来源和范围。只读检查可以先做；涉及覆盖原文件、对外发送、公开发布或付费操作时，先展示具体内容，等我明确决定。

产品里的按钮和组织政策还会继续限制实际操作。你在提示词里写了允许，也不一定越过管理员配置；反过来，工具权限已开，也不表示所有业务动作都符合你这次的意图。

哪些东西不要放进截图和工具包

最常漏的地方常常在四角：左下账号、顶部地址、右侧历史会话、底部本地路径。屏幕中心的图表已经脱敏，边缘仍可能留下邮箱或账号ID。分享之前，把整张图按四角和正文都看一遍。

1. 邮箱、手机号、账号ID和姓名是否需要公开。
2. 地址栏是否含内部租户或资源标识。
3. 配置文件是否露出密钥值。
4. 聊天侧栏是否显示其他项目或私人标题。
5. 截图是不是截到了错误账号或无关窗口。

优先用产品界面收起无关区域，再裁切。必须遮挡时，确认不会让人误以为被遮住的部分支持某项功能。真实证据不需要全屏展示，但不能改造出原来没有的按钮或结果。

团队资料不是一分享就全通

团队使用时，要同时检查人、资料和动作。给同事分享一个agent，并不一定给他所有底层文件权限；把资源加入Space，也不自动覆盖原资源的访问控制。直接上传的文件又有自己的共享范围，前面空间（Spaces）章节已经解释过。

1. 列出实际接收人和需要完成的工作。
2. 只加入这项工作需要的资料。
3. 分别检查资源权限和Space成员。
4. 让接收人从自己的账号测试。
5. 离开项目的成员按组织流程回收权限。

如果对方说打开了页面但看不到答案，先排查资料权限，不要为了省事把整个项目改成公开。一次小范围验证，比交付前集中修复一大批共享问题更容易。

企业治理看官方机制，不借试用账号证明

企业版还涉及管理员自定义权限、日志、访问控制和组织规则。它们帮助公司决定谁能创建、分享和调用哪些能力。这里介绍的是官方机制，本项目没有用企业管理员账号逐项测试。

你要评估公司是否适合使用，可以给管理员一份具体清单：资料是否可以进入该环境、哪些动作必须审批、如何查看记录、成员离职怎样回收、外部链接怎样撤销。问题越具体，答案越能变成实际配置。

日志能回答什么，不能替你决定什么

日志帮助你追溯谁在什么时候做了什么请求，仍需要有人判断那次动作是否符合业务意图。知道一份文件被共享过，不会自动告诉你它适不适合公开；看到一个执行成功状态，也不会替你核验报告数字。

1. 知道组织实际启用了哪些日志。
2. 知道谁有权限查看和处理异常。
3. 敏感操作有明确的业务负责人。
4. 发生误共享时知道怎样撤销并确认效果。

把日常交付标准和技术记录连起来，安全才会落到工作里。产品机制提供边界，团队流程说明谁负责，你自己则需要在关键一步点下去之前看清内容。

任务卡一：一周内容看板

练习目标：把一份小表变成能指导下一周安排的看板。先准备发布日期、内容标题、曝光、阅读、关注、投入时间等字段；没有的字段就留空，不让模型根据其他指标补算不存在的数据。

用附件做一周内容看板。先检查行列、缺失、单位和统计区间。给出三条有数据支持的发现，再做单文件HTML。重点回答：哪些内容值得继续、哪类投入需要调整、还缺什么数据才能判断。只有曝光和阅读时，不要声称已经知道涨粉。模拟数据必须在标题附近标注。

看板首屏只放决策需要的几项指标，详细原表留在后面。你要的是下一周安排依据，不是把所有列转换成更多图。若某个指标无法解释，就先不要把它放大成主结论。

看板验收：比例要能算回来

下面是一份模拟练习：内容A曝光10000、阅读1200、新增关注36、投入3小时；内容B曝光6000、阅读1500、新增关注15、投入1小时。它不能代表花叔任何平台的真实表现。

你可以算出A的阅读/曝光为12%，B为25%；A每小时新增关注12，B每小时15。不同指标会给出不同排序，因此「哪条最好」必须先说明你更关心阅读还是关注，以及投入如何计量。

复核之后还可以做一个反例：把内容B的投入时间改成2小时，其他数据不变。它的每小时新增关注就变成7.5，按这个指标排序会改变。要求agent只更新受影响的比值与排序，保留原阅读转化率；如果它把所有图表一起重做，就继续追问哪一项实际输入发生了变化。

1. 复核分子分母，缺失与0分开处理，百分比不重复乘100。
2. 曝光、阅读与关注分别解释；模拟小样本不推断长期趋势。
3. 颜色、排序与文字结论一致，反例只改变受影响的指标。

只要能亲手复核这两行，你就能判断最基本的计算有没有串。实际工作再增加更多内容之前，先让这两行跑对。

任务卡二：三个选题和一篇初稿

练习目标：把公开信息变成你愿意亲自验证的内容方向。这里不要求每天必写一篇，先挑值得写的事。你可以指定读者是普通订阅用户、内容创作者或小团队负责人，不同读者需要的切入点不同。

请从昨天的AI动态中给三个选题。每个写：事实变化、目标读者为什么关心、可亲自验证的任务、需要核查的数字、预计要准备的材料。优先原始来源，不按转载数量排序。选出最有实证空间的一项，先给大纲；我确认后再写初稿。不要替我编体验，不把发布稿中的承诺写成我的测试结论。

这条提示词用来得到候选与准备清单。你最后可以一个都不选，也可以把最有价值的一项留到材料齐了再写。内容生产的速度，不必靠略过最关键的事实检查换来。

初稿验收：找出作者真正知道什么

看初稿时，先找所有第一人称经历、数字、引用和效果判断。它们是读者最容易相信、也最需要依据的部分。没有真实经历就写操作建议，没有实测就写官方功能说明，两个都可以有用。

1. 第一人称经历都能对应本人的材料或口述。
2. 产品数字有当期官方来源。
3. 引语能在原文复现，概述没有被加成引号。
4. 图片来自真实操作，模拟画面已标明。
5. 标题承诺在正文中有实际兑现。

请只检查初稿的证据：把第一人称经历、数字、引用和效果判断逐条列出来源。缺证据的地方改成有依据的说明或待验证问题，不追加修辞，不重写整篇风格。

最后再问一句：读者看完可以做哪一步？如果只能记住你夸它很强，说明初稿还缺具体任务或结果。

任务卡三：八页汇报PPT

练习目标：把已经确认的分析结论交给一个忙碌的听众。先确定听众要作出的决定：是否继续某项投入、调整哪个工作流程，还是批准下一轮试验。PPT页面顺序应该围绕这个决定展开。

根据已核验的周报结论，做八页汇报。先给每页结论标题、依据和建议图形：1现状，2目标差距，3表现较好项，4异常项，5原因假设，6建议动作，7资源与风险，8需要会议决定的问题。材料不支持某页时说明缺口，不造数字。结构确认后生成可编辑PPTX，保留关键口径与来源。

八页只是这次练习的结构。你实际只有五个有价值的结论，就可以做五页，不必为了页数把同一张图重复三次。

PPT验收：能编辑，也能讲

1. 每页只有一个主要结论，标题不只是「数据分析」。
2. 图表文字在投屏或小预览下可读。
3. 数字与原报告一致，单位和区间没有丢。
4. PPTX中重要文字可编辑，图表形态符合后续需要。
5. 没有把空白占位图或模板说明带进成品。

再做一次口头预演：你只看标题，能不能把八页顺着讲完？如果每到一页都要重新解释为什么突然换话题，结构就还需要调整。演讲备注可以帮助你保留背景，但不能靠密密麻麻的备注补救页面没有结论。

请检查这套PPT的叙事顺序。只指出断裂、重复和没有依据的页面，再给最小调整。不要换整套风格；已核验的数据与图表保持原值。

任务卡四：产品说明或资料阅读页

练习目标：让别人打开一个页面，就知道是什么、适合谁、下一步能做什么。产品说明页与资料阅读页可以共用一个简洁框架，但不要混入未经验证的功能承诺和虚构客户评价。

做一个中文产品说明页。内容只用我提供的资料，包含一句话用途、三个适用任务、实际操作示例、常见问题与下一步入口。没有客户证言就不加，不做虚假数据。先实现手机可读、清楚滚动和必要导航，不收集个人信息。若作为应用（Apps）公开页，先检查使用的集成是否符合当前限制。

如果你做的是本书阅读器，就把下一步入口改为章节导航。让用户立即读到内容，比开头堆满介绍和领取按钮更适合这个任务。

网页验收：从收件人的位置打开

作者自己的编辑器能打开，不能证明所有收件人能用。你至少要试一次目标访问方式：内部页面用实际受邀账号，公开页面用未登录窗口，离线HTML则断网打开本地文件。

1. 第一屏说明清楚页面用途。
2. 长标题、长段落和图片没有跑出边界。
3. 每个按钮确实完成它写的动作。
4. 需要权限时给出清楚提示，没有假装已登录。
5. 分享链接与当前发布版本一致。

请按新读者第一次打开的路径验收：进入首页，找到第二章，调大字号，返回目录，再打开最后一章。只记录实际通过与失败，不用「应该可以」代替测试结果。

交付前把最终访问地址和版本日期记下来。下一次改内容时，才能知道你修的是哪一版，而不会让录屏、书稿和在线页各说各话。

把测试结果保存下来，下一次改版沿用同一路径复测。

把四个任务接起来之前

看板、选题、PPT、网页是四种不同工作，不必为了一个热闹演示把它们强行串成自动流程。如果PPT需要看板结论，就让看板验收通过后再启动；如果选题与它无关，两项可以独立准备。

请为这四项工作列出依赖关系：每项需要哪些输入、交付什么文件、谁验收、什么条件满足后才能继续。只给计划，不立即创建定时任务。没有依赖的工作保持独立；有依赖的工作以「前一步真实完成」为条件，不以猜测的耗时为条件。

错误会沿着任务链传播。第一张表口径错了，后面的PPT和网页可能只是把错误包装得越来越完整。因此每一步留一个小验收，比整条链最后一次大验收更容易修。

团队交接时，给每份输入一个明确版本名。上游重新计算以后，下游要知道哪些页面需要同步，哪些内容没有变化。至少保留一个共同的统计截止日期，别让看板用本周数据、PPT用上周数据、网页又展示另一份模拟数字。

一周后再判断它是否值得留下

用了几次之后，你可以回看这个工具究竟替你减少了哪部分工作：少了抄写、少了找资料、少了重复解释，还是只是把时间转移到了检查输出。这个问题没有统一答案，你的任务和标准决定收益。

1. 记录自己仍需补充的资料。
2. 记录每次返工最常出现的两类问题。
3. 把已经稳定的方法保存成短说明或Skill。
4. 停用总是产生无关结果的重复任务。
5. 保留一份最终能打开的成果作为下次基准。

根据这一周的使用记录，找出最值得保留的一项工作流程和最该暂停的一项。只依据真实记录，不估算没有测过的节省小时数。给下周一个小改动，并写明用什么结果判断它有没有改善。

把工具用得更合适，往往从这样的一个小改动开始。你不需要一次把所有功能都学完。

英文界面词怎样查

本项目桌面版截图主要使用英文UI，回答与内容可以是中文。书里保留关键按钮原名，是让你能在屏幕上找到对应位置。网页账号管理部分出现过中文，因此看到语言不同，先确认是不是换到了另一个入口。

1. Chat：发出当前任务与查看对话。
2. 活动流（Feed）：活动汇总；日历（Calendar）是日历，待办（To-dos）是待办。
3. 成果库（Library）：找成果与资源；Owner表示所有者。
4. 自定义（Customize）：配置Agent配置（Agents）、技能（Skills）、连接器（Connectors）、知识（Knowledge）。
5. 空间（Spaces）：组织项目或团队资料。
6. 任务控制台（Mission Control）：集中看运行与待输入事项。

搜教程时也试英文词。有些旧材料仍使用过去的导航名称，官方文档本身也可能更新不同步。优先核对实际界面与对应版本，不需要把所有旧名字都背下来。

常见状态怎样读

草稿（Draft）表示还在编辑的草稿状态；发布（Publish）把可使用的版本发布出来；分享（Share）设置谁能访问。三个词会在不同资源上出现，含义相关，具体权限仍以该资源的界面为准。

1. 运行中（Running）：仍在执行，先看是否有进展或等待条件。
2. 需要输入（Needs input）：等你提供输入或作决定。
3. 已完成（Completed）：运行已结束，但成果仍需验收。
4. 失败（Failed）：出现错误，保留提示定位问题。
5. 已中断（Interrupted）：中途被停止，不按完整任务计算。
6. Owner、Viewer、Co-owner：对应资源的拥有、查看或共同管理角色，别只凭中文直觉扩大权限。

一个好习惯是，把状态和文件一起看。状态告诉你流程走到哪，文件告诉你交付到底是什么。两者不一致时，先追问差异，而不是只选对自己期待有利的那个信号。

区域与账号问题去哪里确认

官方区域表区分不同能力的可用性。产品某种功能在一个区域可用，不代表所有agent功能、桌面部署或企业集成都同时可用。个人注册路径、组织控制台路径与企业SSO，也需要分别看对应文档。

请根据官方区域文档，确认［我的组织区域］是否支持［具体功能］。区分基础分析能力、agent能力和企业桌面部署。没有明确支持记录就写未知，不把其他区域的说明套过来。请给直接对应的官方页面链接和当前核查日期。

本书不制作容易过期的完整区域对照表，也不依据一次注册失败判断某个国家全部不能使用。若你属于公司账号，把区域、身份类型、所需功能和报错一起交给管理员，通常比反复切换入口更有帮助。

官方文档索引：按问题找

读者页中的官方依据链接直接指向对应章节；离线阅读时可以先记下问题，联网后再查。下面这些入口足够覆盖本书大多数操作。

1. 注册与安装：standalone-signup.html、getting-started-desktop.html。
2. 聊天与成果：working-with-chat-desktop.html、library-desktop.html。
3. 方法与角色：skills-desktop.html、agents-desktop.html。
4. 上下文与工具：knowledge-desktop.html、connections-desktop.html、working-with-spaces.html。
5. 定时与应用：mission-control-desktop.html、getting-started-apps.html。
6. 用量与安全：standalone-usage.html、desktop-security.html、sec-agentic-security.html。

以上页面均位于https://docs.aws.amazon.com/quick/latest/userguide/。把文件名接在这个地址后即可打开。与其记住某次截图里的位置，不如保留按具体问题找到一手文档的办法。

配套包、版本与读完之后

本书配套交付限定为huashu-design、huashu-excel、huashu-report三个MIT公开仓库的轻量导入包。包内保留LICENSE和公开来源；浏览器、外部服务、运行环境与部分大型示例素材不随方法文件自动安装。先解压外层工具包，再逐个导入单项ZIP。

公开来源：github.com/alchaincyf/huashu-design；github.com/alchaincyf/huashu-excel；github.com/alchaincyf/huashu-report。下载版本、固定提交和文件SHA记录在工具包manifest.json中。遇到缺依赖时，从对应仓库说明按需补齐。

书稿版本日期为2026年9月16日，实测材料来自本项目9月14日至16日。后续界面与能力变化，以自己的账号和当期官方说明为准。准备分享时先确认已完成独立审校的版本。

现在可以合上这本书，挑明天的一件小工作去试。先让它交出一份你能检查的结果。花叔。