write-proposal

撰写 Upwork 提案

根据自由职业者的真实资料和工作经历，撰写有针对性的提案。优先考虑相关性和可信度，而不是篇幅或泛泛的说服。

选择账号

调用 list_accounts，并选择一个原始 role 为 TALENT 或 FL_AGENCY 的账号。如果符合条件的账号不止一个，请询问用户。后续每次调用都保留 org_uid 和 role，但提及账号时使用 name 和 role_label。

查看职位

1. 调用 find_jobs，并将 action 设为 get。其 id 参数接受数字职位 ID、~02… 密文或完整的 Upwork 职位 URL，因此用户粘贴的链接可以原样传入。
2. 如果用户提供了搜索词，先用 find_jobs 的 search 操作查找候选职位；如果用户希望根据自己的资料匹配工作，则使用 smart_search 操作。不要将资料技能传入 smart_search；推荐器已经了解该资料。其默认模式为 best_match。每次返回这些搜索结果时，都要说明也可以按 Most Recent 排序；用户要求查看最新工作时，将 mode 切换为 most_recent。日期筛选条件（days_posted 或 from_date / to_date）仅适用于 most_recent；search 操作无法按日期筛选。搜索结果行不包含 connects_cost；用户打开特定职位时，应通过 get 操作读取该信息。结果中 applied 为 true 表示该自由职业者已经申请过——不要再次建议申请。
3. 回复中包含职位信息时，准确列出职位名称、工作范围、预算、必需技能、客户偏好、筛选问题，以及申请所需的 Connects 数量。
4. 职位的 client.rating 是其他自由职业者与该客户合作后给出的平均评分，而不是客户对自由职业者的评分。用户在考虑是否申请时，如果评分较低，应予以说明，并按照响应中的 client_rating_basis 表述来转达，不要自行编造说法。
5. 搜索没有返回任何行时，读取 empty_reason 并说明其含义；不要声称市场上没有职位。如果是 no_personalization，则对整个市场使用 search 操作。如果没有 empty_reason，只说明没有符合这些条件的结果；上游限制也会呈现相同情况，因此不要对此作出断言。

排除已有邀请或提案

起草前必须完成此步骤。Upwork 会在上游拒绝重复申请，因此跳过检查会浪费用户的操作机会，也可能看起来像服务器故障。

• 调用 list_freelancer_proposals，并将 action 设为 invitations。如果该职位来自邀请，请调用 manage_proposals 的 accept_invitation 或 decline_invitation 操作进行回复。不要使用仅适用于非邀请申请的 create 操作。
• 调用 list_freelancer_proposals，并将 action 设为 list，检查同一职位是否已有提案或合同。两个列表操作都会应用默认状态筛选；查找特定状态时，请明确设置状态。
• 提案状态为 Accepted 表示提案已提交并通过验证，不表示客户已接受该自由职业者。优先使用附带的 status_label，它会以通俗易懂的文字说明状态，并将其转达给用户。

收集真实证据

只使用工具返回的信息。绝不编造客户端、赞誉、指标、资质或结果。

• 对于 TALENT 账户，使用 get_profile 的 get 操作获取技能、概述、工作经历和个人资料信号；使用 list_highlights 操作获取作品集项目和证书；使用 connects_balance 操作获取 Connects。对于 connects_balance，balance 是 Connects 钱包。若存在 product_credits，它们只能用于指定产品，不属于该余额——请单独报告。
• 读取自己的个人资料时还会返回 promotions（赚取 Connects 的任务和当前 Freelancer Plus 优惠）。申请时如有相关信息，请提及，并严格按照返回内容分享优惠网址。如果 promotions 包含 error，请说明查询失败，而不要声称没有优惠。
• 如果 Upwork 因不允许此账户提交提案而拒绝 create，请转述拒绝原因，并检查个人资料或控制面板中的 identity_verification，但不要假设这是拒绝的原因。除非用户表示问题已解决，否则不要重试。
• 对于 FL_AGENCY 账户，使用 get_agency 的 get_profile 操作获取机构证据，并使用 get_freelancer_financials 的 connects_balance 操作获取 Connects。机构账户无法使用 get_profile。
• 使用 list_freelancer_proposals 查看之前已提交、已获邀或已雇用的提案，作为写作示例。

起草提案

1. 确定客户的主要目标，并选择最匹配的有力证据。起草前，从 find_jobs 的 get 操作读取 client_feedback，或读取邀请中的 user.name。如果评价或邀请中提到了客户联系人或项目，请在开头称呼该联系人并提及该项目。绝不要编造评价或邀请中未出现的姓名。
2. 撰写简洁的求职信。工具会执行长度上限并报告上限；如果用户提供的文本过长，请让他们缩短，而不要截断后发送。
   • 开篇说明与该职位相关的成果。
   • 将一两个真实案例与所需工作联系起来。
   • 说明切实可行的方法或具体的第一步。
   • 说明重要风险和限制，并分别回答每个筛选问题。
   • 以有用的后续步骤收尾。
3. 如果职位要求使用另一种语言，请同时提供英文提案和该语言的提案。
4. 始终主动提供附件，不要默默跳过附件问题。对于本地文件，普通申请需在 proposals 上下文中开始上传；接受客户邀请时，则需在 invitation 上下文中开始上传。内联上传会直接返回存储的 file_uid 值；使用备用 URL 上传时，必须持续轮询，直到状态为 ok，然后通过 confirm_attachment_upload 确认。将生成的 file_uid 值传给提案。文件只能附加到其上传所在的上下文；上下文不匹配时会被拒绝，必须重新上传文件。对于 TALENT 账户，还要提供 get_profile 的 list_highlights 操作返回的相关作品集项目和证书，并将选中的 ID 作为 certificate_ids 和 portfolio_project_ids 传入。不要对 FL_AGENCY 账户调用 list_highlights；请改用 get_agency 已返回的机构资料证据。
5. 使用用户批准的确切报价，并以数字形式传入 charged_amount。绝不要替换为市场价格或推断金额条款。

提交

1. 总结求职信、筛选问题的回答、报价、附件和亮点，然后在首次调用具有写入能力的工具之前，取得用户的明确确认。
2. 调用 manage_proposals，执行 create 操作。工作引用必须是数字工作 ID，不能是 ~02… 密文。get 操作接受密文或工作 URL，并返回要在此处传入的数字 ID。对于代理机构，省略团队参数；如果代理机构有多个团队，错误信息会列出它们，由用户选择其中一个。
3. 展示返回的预览，并始终说明：
   • 所需 Connects 数量和当前余额；
   • 账户是否具备申请资格；
   • 尚未满足的优选资质，或说明资质检查无法进行；
   • 必填筛选问题的回答；
   • 仅当预览提供了相关信息时，说明竞争报价以及其他申请者的报价；如果预览说明无法获取这些信息，转告用户，并且绝不估算金额；
   • 如果存在 boost.suggested_bid，仅附带其自身说明一并告知，绝不将其改述为申请者报价的占比；
   • 是否可以加价以及 Connects 余额。
4. 让用户决定是否加价以及加价多少。如果无法加价，不要提出加价选项；转告用户 boost.reason。否则，除非 boost.recommendation 为 skip，否则提供加价选项；加价金额不得超出预览所述限制，并且只能按用户批准的金额加价，将该金额作为 boost_connects 传入。提交后，无法通过此工具编辑或撤回报价。如果确认结果表明获批的报价已无法占据付费名额，则未提交任何内容：告知用户需要超过的新报价，并请其批准新的金额。
5. 如果内容或条款有任何变更，使用修正后的值再次调用 create 操作。新的预览将取代待处理的预览。
6. 另行取得用户对提交的明确批准，然后调用 confirm_preview，执行 confirm 操作，传入预览返回的 type，并且只传入返回的 preview_id。新申请和邀请回复会返回不同的类型，因此应使用实际返回的类型，而不要自行假定。
7. 要进行验证，按 Pending 状态列出自由职业者的提案。如果用户进行了加价，则读取 list_freelancer_proposals 的 get 操作，并报告 terms.connectsBid——这是 Upwork 保存的报价，可能与发送的金额不同，且无法通过此工具更改。

如果 Connects 不足，请明确告知用户，并让其补充 Connects 后重试。不要将失败描述为永久性问题。

如果服务端返回首次使用时的市场安全政策提示，请向用户展示该提示。只有在用户明确确认后，才调用 manage_proposals 的 acknowledge_policy 操作，然后重试被中断的操作。

向客户发送消息

自由职业者无法打开提案聊天室，也无法在提案中发送第一条消息。要回复现有对话，请使用 list_freelancer_proposals 的 get_room 操作，或使用 get_messages 的 find_room 操作并设置 context_type=proposal，然后调用 send_message 的 send 操作。如果聊天室尚不存在，请告知用户客户必须先发送消息。若 find_room 返回未找到，则在对话开始前都无法继续。只有在客户发起的对话中，才能提出直接合同提案。

质量规则

• 每份提案都要针对一项具体工作撰写。绝不在不同工作之间重复使用求职信。
• 优先使用具体证据，而非形容词和套话。
• 遵循服务端对标题、标识符和不可信客户撰写文本的展示规则。

工具发现和精简模式请遵循 upwork-workflows 技能。