write-job-post

编写 Upwork 招聘信息

以对话方式引导客户从粗略需求逐步形成可供审核的草稿。每次只问一个重点问题；不要一次性给出冗长的需求收集表。

选择账户

调用 list_accounts，选择一个原始 role 为 CLIENT 的账户。招聘信息发布工具仅限客户使用，其他角色会被拒绝。如果有多个符合条件的客户账户，请询问用户选择哪个账户，并在之后的每次调用中保留 org_uid 和 role。

收集需求

1. 开始发布新信息前，调用 get_job_posting，使用 status: draft 执行 list 操作。如果存在已保存的草稿，询问客户想继续编辑其中一个草稿，还是开始发布新信息。使用 get 操作加载客户选择的草稿；如要继续编辑，使用 post_job 的 update 操作。需要参考语气和结构时，也应查看相关的过往招聘信息，但绝不能沿用旧价格或条款。

2. 每次只澄清一个问题：

   • 要解决的问题或希望达成的结果，以及具体且可验证验收标准的交付成果；
   • 自由职业者能够识别的必备技能名称；
   • 固定价格还是按小时计费，以及客户的确切预算；
   • 所需经验水平和预期项目时长；
   • 对于按小时计费的工作，每周投入时间：全职（每周 30 小时以上）、兼职（每周不足 30 小时）、按需安排或不确定；
   • 时间安排和协作预期。

   其中有些选项受枚举值限制。应从 get_tool_help 中读取可接受的值，不要自行编造格式；用通俗语言询问客户，不要照读代码。

3. 对于按小时计费的工作，在建议费率范围前调用 get_rate_insights 的 get 操作。将市场数据作为参考信息呈现，绝不能擅自更改客户选择的费率。

起草招聘信息

1. 撰写具体的标题和简洁聚焦的描述。工具会强制执行描述的长度上限，并报告该上限；如果客户提供的文本超出限制，请让客户缩短，而不要截断后发送。
2. 涵盖工作范围、交付成果、完成标准、相关背景和限制条件。绝不能添加客户未批准的要求。
3. 技能应使用易于理解的名称，例如 React 或 WordPress。如果近似名称匹配到 Upwork 技能，工具会在 skill_suggestions 中报告，并将 added_as 设为 interpreted（例如将 React.js 识别为 React）；应告知客户这些匹配结果，以便客户更正。无法可靠匹配的名称会作为自定义技能保留（added_as 为 custom），不会阻止草稿生成；应向客户提供预览中报告的近似匹配项。
4. 提出少量针对该工作的筛选问题，并让客户修改或删除这些问题。
5. 询问是否要设置优先资格条件，例如 Job Success Score、英语水平、地点或时区、收入、工作时长、作品集、Rising Talent 或语言能力。说明，设置必需的地点条件可能会排除其他符合条件的申请者。绝不能设置客户未提出的资格条件。
6. 询问谁可以看到招聘信息。服务端要求明确选择可见范围，不会自行猜测，因为错误的值可能会在不提示的情况下将招聘信息设为私密。用通俗语言提供选项——任何人（包括搜索引擎）、仅限已注册的 Upwork 用户，或仅限受邀的自由职业者——如果客户没有偏好，建议选择开放程度最高的选项。
7. 如果招聘信息需要附加文件，请在 job 上下文中启动上传。内联上传会直接返回已存储的 file_uid 值；对于备用 URL 上传，应轮询，直至状态为 ok，然后调用 confirm_attachment_upload 确认。将生成的 file_uid 值传递给招聘信息。

保存草稿，然后发布

1. 概述每个字段，并在首次调用具有写入能力的工具前获得明确确认。
2. 调用 post_job，操作为 create_draft，此操作会返回预览；此时尚未保存任何内容。
3. 使用面向用户的语言展示预览。说明其质量检查清单、推断出的类别、对技能的解读、无法匹配的技能、筛选问题、资格要求、可见性以及确切的金额条款。
4. 如果客户希望修改，请使用修正后的值再次调用 create_draft 操作。新预览会取代待处理的预览，其 preview_id 会取代旧值。切勿手动编辑返回的参数，也不要将它们传入确认操作。
5. 单独获得明确批准以保存草稿，然后调用 confirm_preview，操作为 confirm，使用预览返回的 type，并且仅传入返回的 preview_id。这会在 Upwork 上保存一个真实的 草稿。它绝不会发布职位，也不会让自由职业者看到该职位。
6. 告知客户草稿已保存，并询问他们是否要立即发布。不要假定批准保存草稿也代表批准发布。
7. 只有在客户明确要求发布时，才调用 post_job，操作为 update，并传入已保存草稿的职位 ID 和 status: published。可在同一次更新中包含内容修改。展示带有发布警告的预览，另行获得明确批准，并使用 confirm_preview 确认。
8. 发布后会返回一个新的 job_id；请保留它，以便后续调用，因为草稿 ID 将不再有效。提供返回的职位管理链接，让客户查看已发布的职位。

发布后

• 如需收集申请者，先从 get_job_posting 获取职位发布 ID，然后使用 list_client_proposals 的 list 操作列出该职位发布的提案，或使用 list_all 操作一次性查看所有职位发布的提案。只有针对单个职位发布的 list 操作才会标记置顶提案。
• 如需邀请自由职业者，请使用 find_freelancers，然后调用 invite_freelancer。邀请需要自由职业者的数字人员 ID，而不是其个人资料键。
• 如需修改已发布的职位，请调用 post_job 的 update 操作，传入职位发布 ID 和仅需修改的字段，然后使用 confirm_preview 确认返回的预览。筛选问题可以替换或明确清空；省略筛选问题则会保持不变。也可以修改 experience_level。只有在客户要修改 duration 时才传入该字段；否则会保留当前时长。
• 如需续期已发布的职位，请调用 post_job 的 renew 操作。这会将职位重新置顶到搜索结果中。发布或上次续期 24 小时后方可续期，总共最多续期三次，且无法撤销。如果职位不符合续期条件，响应会包含 status: not_eligible、reason、next_renewal_at 和 renewals_left，且不会有预览——请转告客户并停止操作。如果职位符合条件，请展示预览，并使用类型 job_renew 调用 confirm_preview 确认。续期成功后不要立即重新检查资格；职位发布状态可能需要几分钟才会从续期前状态更新。
• 如需下架职位，先读取职位信息，并确认其状态仍允许移除。如果该状态不允许移除，请告知客户无法移除该职位并停止操作。如果允许移除，请调用 post_job 的 close_reasons 操作，展示返回的所有原因，询问客户适用哪一项，并将客户的选择传给 close 操作。绝不要替客户选择原因。

质量规则

• 优先描述具体结果，而不是宽泛的职责列表。
• 确保验收标准可观察、可测试。
• 筛选问题应能根据真实经历或工作样本作答。
• 绝不编造预算、截止日期、工时、资格要求或法律条款。
• 遵循服务端对标题、标识符和不可信参与者文本的呈现规则。

如需发现工具并使用精简模式，请遵循 upwork-workflows 技能。