Rokcso's Blog

美国 LLC 报税名词解释：给独立开发者的税务入门

hi@rokcso.com (rokcso) — Fri, 06 Mar 2026 10:00:00 +0800

非美国居民的 SMLLC 进行 IRS 税务申报要提交哪些表？

⚠️ 注意：

以下所有名词解释都不是 100% 完整全面的，真正的完整全面可能只有去翻法典，我会省略一些个人认为对于当前我这种「Foreign-owned U.S. DE 的税务申报」相对不重要的信息或者例外，比如 Form 1040 的变体表不止下文提到的几种、不是所有外国公民在判定是否为 NRA 时都需要进行实质居留测试等等；
另外如果再考虑中美所得税协定的内容，情况可能会变得更为复杂，我已经有点难以理清了……所以暂时跳过。等我真的遇到被判定有 USTB、有 ECI 且需要在美国缴纳税款时再研究如何使用中美所得税协定来豁免税款（很有可能不会遇到）。

名词解释

Disregarded entity (DE)

被忽略实体。指在美国所得税层面下，不被视为可与其所有者分离的独立实体。

一般原则：作为 DE，其收入和支出在美国所得税层面下会「穿透」给其所有者，理论上由该所有者申报个人所得税即可（用 Form 1040）。

关键例外：根据美国税法第 6038A 节的要求，Foreign-owned U.S. DE 会被视为一个独立的公司，用于履行特定的申报义务，所以，Foreign-owned U.S. DE 需要由公司申报公司所得税（用 Form 1120），且必须附上 Form 5472。

Foreign-owned U.S. DE

外资美国被忽略实体。指完全由外国个人拥有的美国国内被忽略实体。

一个由非美国税务居民个人 100% 持有的美国怀俄明州 SMLLC 就是一个典型的 Foreign-owned U.S. DE。

NRA

全称 Nonresident Alien（非居民外国人），是美国税法中用于界定个人税务身份的概念，特指那些不满足美国税务居民标准的外国公民。

判定标准依据以下两项测试的反向结果（即两项测试都不通过则为 NRA）：

绿卡测试：如果个人在纳税年度内的任何时间都不是美国合法永久居民（即未持有绿卡），则不通过测试
实质居留测试：如果个人在纳税年度内不满足以下任一条件，则不通过测试
- 本年度在美国境内停留累计超过 31 天
- 本年度及过去两年内，按加权公式计算（本年度累计停留天数 + 去年累计停留天数 / 3 + 前年累计停留天数 / 6）在美国停留的总天数未超过 183 天

ECI

全称 Effectively Connected Income（有效关联收入或实际相关收入），指与非美国居民纳税人在美国境内从事的贸易或业务直接相关并来源于美国境内的收入。

核心判定逻辑：首先判定是否在美国境内从事贸易或业务（USTB，U.S. Trade or Business），然后再界定哪些来自美国境内的收入与此业务存在有效关联。

如果存在 ECI 就需要缴纳联邦所得税，个人提交 Form 1040，公司提交 Form 1120，但是由于 SMLLC 属于 DE，收入「穿透」给个人，所以需要个人提交 Form 1040（或其变体表）。

但是公司也需要在公司层面履行独立的申报义务，提交 Form 1120，如果是 NRA 持有的 SMLLC 则需要提交形式上的 Form 1120 并附上 Form 5472。

Form 1040

全称 U.S. Individual Income Tax Return（美国个人所得税申报表），是 IRS 要求符合条件的纳税人每年提交的联邦个人所得税申报表。

主要供美国税务居民使用，包括美国公民、绿卡持有者以及通过「实质居留测试」被认定为居民的外国人（非 NRA）。

在标准版 Form 1040 之外，还有一系列变体：

Form 1040-SR：专为 65 岁及以上纳税人设计的可选表格
Form 1040-NR：专为非居民外国人设计的用于申报其美国来源收入。当非居民外国人在美国有收入时，必须使用此表格而非标准 Form 1040
Form 1040-X：用于修正已提交的 Form 1040、Form 1040-SR 或 Form 1040-NR

在填报 Form 1040 时，通常还需要附上各种附表来提供额外详细信息，比如：

Schedule C：用于报告自营职业或独资企业的利润或亏损
Schedule A：用于报告逐项扣除额，如医疗费用、州税、房贷利息和慈善捐款
Schedule B：用于报告利息和股息收入
Schedule D：用于报告资本利得和损失

Form 1120

全称 U.S. Corporation Income Tax Return（美国公司所得税申报表），是 IRS 要求符合条件的公司实体每年提交的联邦公司所得税申报表。

作为 C 公司纳税或者通过提交 Form 8832 选择被视为 C 公司纳税的其他形式的公司以及由非美国人或实体持有的美国被忽略实体（Foreign-owned U.S. DE）都需要提交 Form 1120。

但是 Foreign-owned U.S. DE 提交 Form 1120 并非因为该实体需要像 C 公司一样缴纳所得税，而是为了履行其特别的信息申报义务，并且 Foreign-owned U.S. DE 提交的 Form 1120 只是 Pro Forma 形式，只需要填写基本信息即可，不需要填写任何财务数据。

Foreign-owned U.S. DE 在提交 Pro Forma Form 1120 时还必须附上 Form 5472，用于报告其与外国关联方的交易信息。其实该 Pro Forma Form 1120 主要是作为 Form 5472 的「封面」，满足形式要求，真正的重点是 Form 5472。

Form 5472

全称 Information Return of a 25% Foreign-Owned U.S. Corporation or a Foreign Corporation Engaged in a U.S. Trade or Business（美国 25% 外资控股公司或在美国从事贸易或业务的外国公司信息申报表），是 IRS 要求特定公司提交的一份信息申报表。

其本身并非用于计算和缴纳税款的税表，而是 IRS 监控和追踪跨境关联交易信息的工具。即使公司没有收入、没有税务义务，也必须提交，如果不提交，每次最低 $25,000 罚款。

总结

我们只需要将报税分成两条线来分析，个人和公司，两者相互独立但是又有一定关联。

首先对于个人，由于我是非美国居民（NRA），且没有 ECI，所以不用申报个人所得税，即不用提交 Form 1040-NR。

其次对于我的美国 LLC，是 Foreign-owned U.S. DE，所以公司所得税「穿透」到个人，理论上公司不用申报，由个人申报，但是个人是 NRA 且没有 ECI，所以个人也不用申报。

但是由于美国税法第 6038A 节的要求，Foreign-owned U.S. DE 有特别的申报义务，但是做了简化，不用提交标准的 Form 1120，而是提交形式上的 Form 1120 并附上 Form 5472。

另外如果我个人层面的所得税在未来被判定为有 ECI，但是如果没有中美所得税协定中规定的常设机构，则可以利用中美所得税协定，在提交 Form 1040-NR 的同时附上 Form 8833 引用协定豁免缴纳税款即可。

Mercury 企业账户申请全流程和审核经验分享

hi@rokcso.com (rokcso) — Fri, 27 Feb 2026 10:00:00 +0800

我的美国公司的 EIN 终于申请下来了，现在开始开通 Mercury 企业账户。经历了 2 次补充审核资料，整体不到 2 天就审核通过了。

本文将分享申请全流程和审核经验。

申请过程

注意：具体流程或者页面显示内容可能并非 100% 一致，但是核心流程节点以及问题处理思路是值得参考的。

前提条件：

美国公司
EIN
护照

注册账号

这一步核心是验证邮箱注册 Mercury 账号，后续账户申请以及其他账户相关操作都是关联在这个账号下面的。关于账号邮箱，有看到一些文章说需要用企业邮箱，但是我使用的是 Gmail 邮箱，依然没有问题。

首先访问 Mercury 官网，点击「Open Account」。

🎁 通过该链接 👆 申请福利：

在 90 天内入金 $10,000 可获得 $250 奖励

可以跳过审核队列，获得快速审核

填写姓名，一定真实姓名，中文则转拼音，参考护照上的英文名。

输入邮箱并设置密码，选择 Account type 为「Business」。

稍等一会邮箱应该会收到一封邮件要求验证邮箱地址。

完成邮箱地址验证后返回账户申请页面填写公司信息。

填写公司信息

首先输入公司名称，注意看页面提示 This will appear on your Mercury account, but doesn’t have to be your legal or trade name (you’ll add that later).，即这个名称只在 Mercury 内部使用，不必是公司法定名称，并且后续可以更改。但是也建议和公司法定名称保持一致。

然后设置 Mercury callsign，可以理解为代号或者用户名，且也只在 Mercury 内部使用。但是全 Mercury 唯一，不能和别的账号冲突，且后续无法更改。

然后选择 Is your company any of the following?，通常选择「None of the above」。

继续填写公司信息，这里：

Legal business name：需要和公司法定名称完全一致，参考公司成立文件
Country of incorporation：选择公司注册的国家「United States」
Phone number：可以使用 +86 手机号码
Company website：虽然为选填，但是建议填写一个看上去相对正式的公司网站
Employer Identification Number：如实填写
Industry：如实选择
Company type：如实选择
Company description：如实填写（AI 生成）
Major investors：选填，一般没有可留空

然后填写公司地址，注意需要填写公司法定地址，如果是通过注册代理机构注册的公司，注册代理机构提供的公司地址也是可用的，可以参考公司成立文件。

然后填写公司物理地址，即公司日常运营、办公或公司创始人个人居住的地址，不必和公司法定地址一致，但一定要真实可验证，中国地址也是可以的，中文则转拼音。

填写个人信息

然后填写公司所有权（人）信息，Single-Member LLC 就填写自己的个人信息即可。

姓、名：如实填写，中文则转拼音，参考护照上的英文名
Email：如实填写，可以和注册账号的邮箱一致
Job title：可选 Founder
Ownership percentage：可填 100%

注意这一页填写完成后点击「Continue」继续填写个人信息。

Citizenship status：选 Non-Resident
Phone number：可以使用 +86 手机号码
Date of birth：如实填写
Residential address：居住地址

由于刚刚的公司物理地址填写的就是个人居住地址，所以可以勾选 Residential address is the same as company physical address，如果不是则自行如实填写即可。

Identification：需要使用手机拍摄护照（建议使用护照而不是其他身份证件）首页并上传

点击「Verify Identity」会出现一个二维码，用手机扫码进入拍照页面，如果进入拍照页面失败则可以在申请页面手动选择文件上传护照照片。

上传护照后还需要使用设备摄像头自拍一张，也有可能需要配合要求点头摇头。

Professional social media presence：选填

PS：写这篇文章时才注意到要求的是 Professional 的社交媒体链接，一般推荐使用 LinkedIn，而不是 X。😅

填写完成后点击「Save」，然后 Who has the primary responsibility to control, manage, or direct the company’s business? 处选择刚刚填写的个人信息，再勾选下方声明信息后点击「Next」。

上传公司文档

这一步需要将公司成立文件和 EIN 证明文件上传给 Mercury，但是 Mercury 也有可能自动完成验证，则不需要上传，直接「Next」即可。

一般在公司 EIN 申请成功后一两周再申请 Mercury 则不需要手动上传相关文件。

填写账户使用声明

可以直接参考下图选择。

需要注意 Where will your first deposits come from? 问的是你的首笔资金来源，有些文章提到选择 Self 可能需要额外验证，选择 Revenue 则不需要，但是我这次申请选择的 Revenue 实际也要求验证收入来源，所以这里各位可根据实际情况或者提供验证文件的难易程度自行判断选择。

这里也是我后续需要两次补充审核资料的关键。

接下来验证物理地址，我使用的是招商银行信用卡账单，其中姓名和地址都是中文，没有英文翻译，但是 Mercury 其实也能自动识别，推测是直接转拼音。所以可见识别判定结果中地址验证无误，但姓名识别判定不一致，因为我在 Mercury 填写的姓名是 San Zhang，信用卡账单中的姓名转拼音是 Zhang San。

当然这里验证不通过并不影响申请流程继续进行。

最后下方 Do you think you’ll be using your Mercury account for any of these things? We’ll note these down to reduce potential follow-up later 选择「None of the above」后点击「Review Your Application」。

最后再 Review 一遍自己的申请信息，确认无误后最下方勾选同意协议后点击「Submit Application」。

等待审核 & 补充资料

提交申请后进入这个页面，可能会要求 Submit additional info，也有可能要求等待 In review，还有可能直接 Account ready。

在这个页面等待审核期间可能会要求你进行一些设置操作，基本都可以跳过，可以自行看页面提示。

如果被要求补充资料，Mercury 是会邮箱提醒的，错过了这个页面可以翻翻邮箱。

第一次补充资料

我第一次被要求补充 Revenue 相关证明资料（推测是由于上面账户使用声明中选择了 Revenue 为首笔资金来源），以及被要求补充地址证明资料（推测是由于刚刚地址验证时姓名没有验证通过）。

解题思路：关于 Revenue 主要是需要证明首笔资金来源是真实存在的，如果首笔资金来源是 Revenue 就提供相关收入证明，如果没有相关收入证明则可以提供一些产品信息告诉 Mercury 你有能力通过 Revenue 获得首笔资金。如果首笔资金来源是 Self 就提供个人收入证明告诉 Mercury 你个人能提供首笔资金。

关于地址验证则帮助 Mercury 判断你的地址、姓名是真实的。

我提交了什么？

关于 Revenue 我和 AI 一起写了一个文档（提交时翻译为英文并转 PDF 上传），介绍我公司的产品（网站地址、体验账号、演示截图）、用户量访问量等后台数据截图、Google AdSense 等后台截图，用户、客户沟通邮件截图等。

关于地址验证我也和 AI 一起写了一个文档（提交时翻译为英文并转 PDF 上传），解释了中文姓名、中文姓名拼音和英文姓名在格式上的差异，说明 San Zhang = Zhang San，并且提供护照、驾驶证等图片佐证姓名问题，并再次提供了招商银行信用卡账单，添加了一些英文标注帮助 Mercury 理解中英文姓名和地址的对应关系，甚至附上了维基百科链接以供参考。

第二次补充资料

等了大概 1 天，我再次被要求补充资料，首先要求阐述我的目标客户以及公司主要服务哪些行业，让 AI 了解我的产品后帮我撰写了一下，注意这里有字数限制，一定要简明扼要且真实。

然后依然要求我上传 Revenue 相关证明资料，但是这次的提示文案非常清晰的指出：我似乎选择了收入作为公司的资金来源，但是没有提供有效的文件来验证资金来源。并且最后提供了一个 I don’t have this document 的选项（第一次补充资料时是没有的），明确告知如果我没有这些文件，请告知 Mercury 我为何不能提供资金证明。

由于第一次补充资料我已经试图证明我有收入作为资金来源了，但是 Mercury 依然让我补充，所以这次我直接选择 I don’t have this document，然后填写原因，大意：

我第一次补充资料中提供了公司部分产品、数据、客户往来截图，但是我无法提供正式文件，因为：

广告平台为自动结算，没有签署合同
产品用户都是 C 端用户，我还没有打通收款能力，只能通过聊天工具收款，没有合同或支付平台（Stripe 等）的流水证明
B 端客户正在洽谈中，还没有签署合同
公司已有多款产品上线，并有真实用户，正在产生收入

这次补充资料后等待了几个小时我的开户申请就审核通过了。🎉

总结

Mercury 的审核的主要目的是验证你的公司以及公司的业务的真实性，遇到审核问题就按照这个思路去应对即可。

译> 我如何使用 Claude Code

hi@rokcso.com (rokcso) — Tue, 24 Feb 2026 10:00:00 +0800

我目前使用 Claude Code 的方式基本遵循「规划 –> 实施」的工作流，但是每一个环节的具体执行上其实还不够到位，我用过 Claude Code 内置的规划模式，也用过 OpenSpec 这种比较「重」的规划模式，感觉 Boris Tane 所分享的这种工作流是介于二者之间的恰到好处，值得尝试。

除了在规划阶段投入精力，及时止损也很重要，不要在投入太多精力让 Claude Code 修复它之前产出的错误结果，直接撤销从头再来通常更为高效。

本文翻译自 How I Use Claude Code，作者 Boris Tane

译文由 AI 翻译，rokcso 修正

我使用 Claude Code 作为主力开发工具已有大约 9 个月了，最终形成的工作流与大多数人使用 AI 编程工具的方式截然不同。多数开发者习惯于输入提示词、偶尔启用规划模式、修补错误、循环往复。更极端的用户则热衷于缝合各种技术黑话 —— 拉尔夫循环、MCP 协议、Gas Town（还记得这些吗？）等等。但无论是哪种方式，一旦涉及复杂场景便会土崩瓦解，产出的结果往往杂乱无章且难以维系。

我将要介绍的工作流有一个核心原则：在审查并批准书面方案之前，绝不允许 Claude 编写代码。这种规划与执行相分离的原则是我实践中最关键的突破。它不仅避免了无效劳动，让我始终掌控架构决策主导权，更重要的是，相比直接生成代码，这种模式能用更少的 token 消耗产出质量显著提升的成果。

graph LR
    A["研究"] --> B["规划"]
    B --> C["注释"]
    C --> | 重复 1-6x | C
    C --> D["任务清单"]
    D --> E["实施"]
    E --> F["反馈与迭代"]

第一阶段：研究

每个有价值的任务都始于一条深入研究指令。我会要求 Claude 在开展任何实际操作前，彻底理解代码库的相关部分。关键在于：所有研究发现必须写入可持续维护的 Markdown 文档，而绝不仅仅是聊天窗口中的临时性文字摘要。

深入阅读这个文件夹，彻底理解其工作原理，了解其功能以及所有具体细节。完成之后，将你的学习成果和发现详细记录在 research.md 文档中

深入研究通知系统，彻底理解其工作原理，并撰写一份详细的 research.md 文档，包含关于通知工作原理的所有信息

深入研究任务调度流程，彻底理解其工作原理，寻找潜在的错误。系统中确实存在错误，因为它有时会运行本应取消的任务。继续研究流程，直到找到所有错误，不要停止，直到所有错误被发现。完成后，在 research.md 中详细记录你的发现

注意这些措辞：「深度地」、「详细地」、「关注细节」、「全面地」。这不是无关紧要的。如果没有这些词，Claude 只会浅尝辄止。它可扫读文件，仅在函数签名层面了解其功能，然后跳过。你必须明确表示不能只做表面阅读。

书面文档（research.md）至关重要。这并非为了让 Claude 完成作业般的形式主义，而是我进行审查的基准界面。通过阅读这份文档，我能验证 Claude 是否真正理解了系统架构，并在制定规划前及时纠偏。若前期研究有误，后续规划必将出错，最终实现自然也会失败。输入的是垃圾，输出自然也是垃圾。

这正是 AI 辅助编程中最需要警惕的失败模式，问题并非出在语法错误或逻辑缺陷，而在于那些孤立运行正常却破坏系统整体性的实现。比如某个函数忽略了现有的缓存层，一次数据迁移未遵循 ORM 的规范，或是新增 API 端点重复实现了既有逻辑。而前期研究阶段正是杜绝此类问题的关键防线。

第二阶段：规划

在我审阅完研究报告后，会要求在一个独立的 Markdown 文件中提供详细的实施方案。

我想构建一个新功能（名称和描述），该功能扩展系统以执行（业务成果）。编写一个详细的 plan.md 文档，概述如何实现此功能。包含代码片段

列表接口应支持基于游标的分页，而非偏移量。请编写一份详细的 plan.md，阐述如何实现此功能。在提出修改建议前，务必阅读源文件，并依据实际代码库制定计划

生成的方案始终包含以下要素：详细的方法说明、展示具体修改的代码片段、涉及变更的文件路径，以及相关的考量因素与利弊分析。

我习惯使用自己的 .md 规划文档，而非 Claude Code 内置的规划模式。内置的规划模式实在难用。我的 Markdown 文件能让我完全掌控，既能在编辑器中自由修改，又可添加行内注释，更重要的是它能作为实际成果永久存储在项目里。

我有个常用的技巧：当需要开发独立功能时，如果曾在开源项目中见过优秀实现，我会将参考代码与需求说明一并提交。比如要实现可排序 ID 功能，就直接粘贴某个项目的 ID 生成代码，附上说明「这是别人实现可排序 ID 的方案，请据此撰写 plan.md 说明如何采用类似方案」。实践表明，当 Claude 拥有具体参考实现而非从零设计时，工作效果会显著提升。

不过，规划文档本身其实不是重点。真正的精髓在于后续的展开。

注释循环

这是我工作流中最具特色的环节，也是我个人价值贡献最集中的部分。

graph TD
    A[Claude 编写 plan.md] --> B[我在编辑器中审阅]
    B --> C[我添加行内注释]
    C --> D[将文档重新发给 Claude]
    D --> E[Claude 更新 plan.md]
    E --> F{满意？}
    F -->|No| B
    F -->|Yes| G[请求任务清单]

当 Claude 输出规划方案后，我会在编辑器中打开文档，直接添加行内注释。用来修正不合理的假设、否决某些实现路径、增加技术约束条件，或是补充 Claude 所欠缺的领域知识。

注释的篇幅差异极大。有时仅需两三个字，比如在 Claude 标记为「可选」的参数旁写上「必填」；有时则需一大段话，阐释某个业务逻辑的来龙去脉，或是直接粘贴代码片段示范预期的数据结构。

以下是我实际添加注释的几个真实样例：

使用 drizzle:generate 来处理数据库迁移，而不是直接编写原始 SQL—— 这是 Claude 缺乏的领域知识
不，这应该是 PATCH 请求，而不是 PUT 请求 —— 纠正一个错误的假设
我们不需要缓存，直接删除这个部分 —— 拒绝一个提案
队列消费者已经处理重试，因此这个重试逻辑是多余的。直接删除它，让程序直接失败。 —— 解释为什么某事应该改变
这是错误的，可见性字段需要位于列表本身上，而不是单个项目上。当一个列表是公开的，所有项目都是公开的。相应地重新构建模式部分。 —— 重定向整个计划的一部分

然后我将文档重新发给 Claude：

我在文档中添加了几条注释，请处理所有注释并相应更新文档。暂不实现

这个循环重复 1 到 6 次。显式的「暂不实现」是必不可少的。没有它，Claude 会立刻跳到编写代码，只要它认为规划足够好。只要在我确认它足够好之前，它都还不够好。

为什么效果如此出色

这个 Markdown 文件在我和 Claude 之间是共享可变状态。我可以按自己的节奏思考，精确标注错误之处，重新参与讨论而不丢失上下文。我并非试图在聊天消息中解释所有内容，而是在文档中直接指出问题所在并写出更正。

这本质上与试图通过聊天消息来指导实施是不同的。这个规划是一个结构化、完整的规范，我可以全面地审查。聊天对话是我需要滚动查看才能重建决策的内容。规划每次都更好。

经过三轮「我添加注释，更新计划」可以将一个通用的实施规划转变为与现有系统完美契合的规划。Claude 在理解代码、提出解决方案和编写实现方面非常出色。但它不了解我的产品优先级，不了解我的用户的痛点，也不了解我愿意做出的工程权衡。注释循环是我注入这种判断的方式。

任务清单

在实施开始前，我总会先要求将任务分解得尽可能详细：

在规划中添加一份详尽的任务清单，涵盖所有阶段及完成规划所需的各项具体任务，暂不执行

这会创建一个清单，用作实施过程中的进度跟踪器。Claude 会随着进展自动标记项目为已完成，因此我随时可以查看规划，准确了解当前进度。这对于进行数小时会话的场景尤其有用。

第三阶段：实施

当规划准备就绪后，我会下达实施指令。我已经将其精炼成一个标准提示词，并在各个会话中重复使用：

全面实施。当任务或阶段完成后，请在规划文档中将其标记为已完成。不要停止，直到所有任务和阶段都完成。不要添加不必要的注释或 jsdocs，不要使用任何或未知的类型。持续运行类型检查，确保不会引入新的问题。

这个提示词包含了所有关键内容：

全面实施：严格按照计划完成所有内容，不挑拣部分
在规划文档里标记为完成：规划是衡量进度的基准
不停止，直到所有任务和阶段都完成：流程中不暂停确认
不要添加多余的注释或 jsdocs：使代码保持简洁
不要使用任何或未知的类型：坚持严格的类型规范
持续进行类型检查：在项目最终完成前尽早捕捉问题

我几乎在每次实施过程中都使用这个措辞（略有变化）。当我说「全面实施」时，所有决策都已做出并验证。实施变得机械而非创造性，这是有意为之。我想让实施过程变得枯燥乏味，创造性的工作发生在注释循环。一旦规划正确，实施就应该是直截了当的。

如果没有规划阶段，Claude 通常会过早地做出一个看似合理但实际上错误的假设，并在此基础上进行大约 15 分钟的构建，然后我不得不逐一撤销这些更改。「不要立即实现」的防护措施可以完全避免这种情况。

实施过程中的意见反馈

一旦 Claude 开始实施规划，我的角色就从架构师转变为监督者。我的提示变得非常简洁。

graph LR
    A[Claude 实施] --> B[我审查/测试]
    B --> C{正确？}
    C -->|No| D[简洁的纠正]
    D --> A
    C -->|Yes| E{更多任务？}
    E -->|Yes| A
    E -->|No| F[完成]

规划注释可能是一个段落，但实施更正通常只是一句话：

你没有实现 deduplicateByTitle 这个函数。
你应在管理应用中构建设置页面，而不是主应用中，移动它。

Claude 对整个规划和当前会话都有全面的了解，因此只需简洁的更正即可。

前端开发是最需要不断迭代的部分。我通常在浏览器中测试，并迅速做出调整：

更宽
始终裁切
有 2px 的间隙

遇到视觉问题时，我有时会附上截图。一张表格错位截图比文字描述更能快速传达问题。

我也经常参考已有代码：

这个表格应该与用户表格完全一致，表头、分页和行密度都应相同。

这种方法比从零开始描述一个设计要精确得多。成熟代码库中的大多数功能都是基于现有模式的变体。因此，新的设置页面应该与现有的设置页面保持一致。通过参考现有页面，可以传达所有隐含的要求，无需详细说明。Claude 通常会在进行更正之前读取参考文件。

当事情出现偏差时，我不会尝试去修补。我会回滚并重新规划，通过舍弃 Git 的更改：

我已经恢复了一切。现在我只想要让列表视图更简洁，其他什么都不需要。

进行回滚后缩小工作范围，通常比试图逐步修正错误的方法效果更好。

保持在掌控之中

虽然我把实施任务委托给 Claude，但我从不给它完全的自主权去决定构建什么。我在 plan.md 文档中负责绝大部分的主动指导。

这很重要，因为 Claude 有时会提出技术上正确但对项目不合适的解决方案。或许这个方法过于复杂，或者它改变了其他系统部分依赖的公共 API 签名，或者它选择了一个更复杂的选项，而一个简单的选项就足够了。Claude 没有关于整个系统、产品方向和工程文化的背景信息。

graph TD
    A[Claude 提出提案] --> B[我评估每一项]
    B --> C[原样接受]
    B --> D[修改提案]
    B --> E[跳过/移除]
    B --> F[覆盖技术选择]
    C --> G[精炼的实施范围]
    D --> G
    E --> G
    F --> G

在提案中进行挑选：当 Claude 提出多个问题时，我会逐一处理：「第一个问题直接用 Promise.all 就行，别搞太复杂；第三个问题单独提取成函数，提升可读性；第四个和第五个忽略掉，不值得为此增加复杂度。」。我正基于当前最紧要的知识点，逐项做出决策。

范围裁剪：当规划包含锦上添花的功能时，我会果断削减。「将下载功能从计划中移除，我现在不想实现这个。」。这能有效防止范围无限制扩大。

保护现有接口：当我明确某些内容不应更改时，我会设置硬性约束：「这三个函数的签名不应更改，调用方必须适配，而非修改库本身。」

覆盖技术选择：有时我有特定的偏好（这是 Claude 无法知晓的），比如*「使用这个模型而非那个」或「使用这个库的内置方法而非编写自定义方法」*。快速、直接的覆盖操作。

Claude 负责具体实施，而我负责关键决策。规划预先就明确方向，选择性指导则处理实施过程中出现的小细节。

单个长时间会话

我倾向于在单个长时间会话中完成研究、规划和实施，而非拆分为多个独立会话。一次会话可能从深度阅读某个文件夹开始，经过三轮规划注释，然后执行完整实施方案，全程在连续对话中一气呵成。

实际上我并未遇到像大家说的那样上下文窗口占用超 50% 后的性能衰减。因为当我说「全面实施」时，Claude 早已在整个会话中持续构建认知：在研究阶段阅读文件，在注释循环完善思维模型，并吸收我提供的领域知识修正。

当上下文窗口满载时，Claude 的自动压缩机制会保留足够上下文以保持进程连贯。而作为持久性产物的规划文档，能在压缩过程中完整保留全部信息精度。我可以在任意时间点指引 Cluade 查阅该文档。

一句话概括

深度阅读，制定规划，反复注释直至计划完善，然后放手让 Claude 连续全面实施，过程中进行类型检查。

仅此而已。无需魔法提示词，无需复杂的系统指令，无需奇技淫巧。只需要一套将思考与执行分离的规范流程。前置研究能防止 Claude 做出无知的改动，详细规划能避免其错误修改，注释循环则注入我的判断力。而在所有决策敲定后，一条实施指令即可让它心无旁骛地持续运转。

试试这套工作流，你会惊讶于从前没有注释规划文档作为缓冲时，自己究竟是如何用编程 Agent 完成任何项目。

译> 我的 AI 应用之路

hi@rokcso.com (rokcso) — Mon, 09 Feb 2026 10:00:00 +0800

本文翻译自 My AI Adoption Journey，作者 Mitchell Hashimoto

译文由 AI 翻译，rokcso 修正

我的经验是，任何有意义的工具，都要经历三个阶段方能掌握：（1）低效适应期（2）基本应用期（3）革新蜕变期。

由于已有得心应手的工作流，我往往要逼着自己突破前两个阶段。尝试新工具总像额外负担，虽心有不甘，但为成为全面发展的多面手，我总会坚持投入。

这是我探索 AI 工具价值的历程，以及正在探索的新可能。在当下众声喧哗的 AI 热潮中，我希望能以这份审慎从容的思考，记录自己对 AI 认知的演进轨迹。

本文全程手写，字字皆出己思。在此强调似乎多余，但鉴于主题特殊性，特此说明。

第一步：告别聊天机器人

请立即停止试图通过聊天机器人（如 ChatGPT、网页版的 Gemini 等）完成实质性工作。这类工具确有价值，也是我日常 AI 工作流的一部分，但它们在编程领域的效用极其有限，因为你本质上是在赌训练数据能恰好生成正确结果，而纠错过程更需人工反复指正，效率低下。

我相信多数人的 AI 初体验都始于聊天界面，编程初尝试也是让聊天机器人代写代码。

在我仍是 AI 怀疑论者时，曾将 Zed 编辑器命令面板的截图粘贴至 Gemini，要求其用 SwiftUI 复刻，当它在数秒内交出近乎完美的成品时，确实令我震撼。如今 Ghostty for macOS 的默认命令面板，正是在 Gemini 生成的代码基础之上微调而成。

但当我试图在其他任务中复现这种成功时，结果往往令人失望。尤其在已有项目中，聊天机器人频繁输出低质结果，让我陷入复制粘贴代码和命令输出的繁琐循环。这种模式效率之低下，明显不如亲自动手。

要真正释放价值，必须转向使用智能体。这是行业公认的术语，指具备循环交互能力并能触发外部行为的 LLM 系统¹。一个合格的智能体至少应具备：文件读取、程序执行和 HTTP 请求发起能力。

第二步：复刻你的工作流程

我接下来的尝试是使用 Claude Code。长话短说：初期体验并不惊艳。产出质量不尽人意，总觉得需要逐行修改，耗时甚至超过亲手完成。尽管研读了技术博客、观看演示视频，仍未见其精妙之处。

但我没有放弃，而是强制自己用智能体复现所有手动提交的代码。字面意思地将同一项工作重复完成两次。先手动实现，再引导智能体产出功能与质量完全相同的结果（当然不会让它参考我的手写代码）。

这个过程堪称煎熬，因为它违背了「高效完成」的基本诉求。但多年使用非 AI 工具的经验告诉我，磨合期的阵痛在所难免，唯有全力尝试后才能得出经得起推敲的结论。

正是在这种刻意练习中，专业认知逐渐形成。我很快从第一性原理出发，验证了他人已提出的观点，而亲身体验带来的理解更为深刻：

任务拆解：将复杂任务拆分为清晰可行的子任务，避免试图「一步登天」
规划分离：模糊需求应先进行规划，再执行实施
自检机制：赋予智能体验证自身工作的能力，它往往能自主修正错误并防止倒退

更重要的是，我摸清了当时智能体的能力边界：擅长什么、不擅长什么，以及如何在其优势领域达成目标。

这一切带来显著的效率提升，以至于我开始自然而然地使用智能体，虽然尚未感觉更快（因为多数时间仍在监督执行），但至少不再迟滞。

特别需要强调的是：效率提升部分源于懂得何时不使用智能体。明知会失败仍强行调用纯属浪费时间，而具备这种避坑意识本身就是一种节约时间²。

至此，智能体已足够好用，我乐意将其纳入工作流，虽未实现净效率增益，但作为工具已令我满意。

第三步：日结智能体

为了进一步提升效率，我开始尝试新模式：每天留出最后 30 分钟，启动一个或多个智能体任务。我的假设是：如果智能体能在我无法工作的时间段取得进展，或许能实现效率增益。本质上是将生产力从「拥有的时间」延伸到「本不工作的时间」。

与上一阶段类似，初期尝试既无成效又令人烦躁。但我很快发现了适合此模式的三大场景：

深度调研任务：让智能体系统梳理某个技术领域，例如检索特定语言中符合某许可证类型的所有库，并为每个库生成多页评估报告，涵盖优劣分析、开发活跃度、社区反馈等。
并行探索概念：同时启动多个智能体验证不同设想。我不期望它们直接产出可交付成果，但能为次日工作揭示潜在盲区。
Issue 与 PR 分类：智能体擅长使用 GitHub CLI 工具，我编写脚本批量启动并行任务进行分类。仅允许生成报告而非直接回复，次日可根据报告优先处理高价值或低耗时任务。

需要说明的是，我并未像某些实践者那样让智能体整夜循环运行。多数任务能在半小时内完成。但关键在于：工作日下午的我通常处于精力低谷，效率低下，此时转为启动智能体任务，反而能为次日早晨提供「热启动」，让我更快进入工作状态。

至此，我开始感受到 AI 带来了超越以往的产能提升，尽管幅度尚微，但已足够令人欣喜。

第四步：外包「稳赢」任务

此时，我已经非常清楚 AI 擅长和不擅长哪些任务。对于某些特定任务，我能高度确信 AI 能给出基本正确的解决方案。因此，我旅程的下一步是：在我处理其他任务的同时，让智能体包揽所有那些它擅长的工作。

更具体地说，我每天会先查看前一夜分类智能体的结果，手动筛选出那些智能体几乎肯定能完美解决的 Issue，然后让它们在后台运行（一次一个，不并行处理）。

与此同时，我会去处理别的事情。我不会去刷社交媒体（和使用 AI 之前一样），也不会看视频等等。我会进入自己惯有的、AI 出现之前的深度思考模式，去处理我想做或必须做的任务。

这个阶段非常重要的一点是：关闭智能体的桌面通知。上下文切换的成本非常高。为了保持效率，我发现我的职责是掌控何时去打断智能体，而不是反过来被它打断。不要让智能体通知你。在你工作的自然间隙，切换标签页去检查它的进度，然后继续你的工作。

重要的是，我认为「处理其他任务」这一点有助于抵消广为人知的 Anthropic 关于技能形成的论文中提到的影响。这其实是一种权衡：你将任务委托给智能体，可能会影响你在这些任务上的技能形成，但同时你通过继续手动处理的任务，技能仍在自然地形成。

到了这个阶段，我已经坚定地处于「绝不可能再回到过去」的状态了。我感觉效率更高了，但即便没有，我最喜欢的一点是，我现在可以将编码和思考的精力集中在我真正热爱的任务上，同时又能妥善完成那些我不太喜欢的任务。

第五步：设计约束框架

有一点可能显而易见：当智能体首次就能产出正确结果，或者最差也只需极少修改时，其效率会大幅提升。实现这一目标最可靠的方法是，为智能体提供快速、高质量的工具，使其能自动判断对错。

我不知道业界对此是否有广泛接受的术语，但我逐渐称之为「约束框架」。其核心思想是：每当你发现智能体犯错时，就花时间设计一种解决方案，确保该智能体永不再犯同样的错误。这里我不需要创造新术语；如果已有其他术语，我很乐意采纳。

这主要体现在两种形式中：

改进隐式提示（AGENTS.md）。针对简单问题，比如智能体反复运行错误命令或使用错误 API，更新 AGENTS.md（或类似文件）。这里有一个 Ghostty 的示例。该文件中每一行都基于一次智能体的不当行为，而它几乎完全解决了所有这些问题。
实际的程序化工具。例如，用于截图、运行筛选测试等的脚本。这通常与 AGENTS.md 的更改配合使用，以让智能体知晓这些现有工具。

这就是我目前的状态。每当看到智能体做出不当行为时，我都会认真投入努力以防止它再次犯错。或者反过来，我正努力让智能体能够自我验证其行为是否正确。

第六步：保持智能体持续运行

在与第五步同步推进的同时，我还设定了一个目标：始终保持至少一个智能体在运行。如果没有智能体在运行，我会问自己：「现在有什么事情可以让智能体替我处理吗？」

我特别喜欢将这个目标与 Amp 的深度模式这类速度较慢但更善于思考的模型结合使用（该模式基本上就是 GPT-5.2-Codex），它可能需要超过 30 分钟来完成一些小改动。但好处是，它往往能产出非常出色的结果。

我（目前？）还没有运行多个智能体，也暂时不打算这样做。我发现，现阶段只运行一个智能体，对于我平衡两方面需求很合适：既能进行我喜欢的深度手动工作，又能照看我那位有点「笨拙」却又莫名高效的神秘机器人伙伴。

「始终保持智能体运行」这个目标目前仍然只是一个目标。可以说，目前在一个正常的工作日里，我大概能有 10% 到 20% 的时间有效地让一个智能体在后台运行。但我正在积极努力提升这个比例。

我不想为了运行智能体而运行智能体。我只在认为某项任务真正对我有帮助时才会启动它们。这个目标的部分挑战在于，需要改进我自己的工作流和工具，以便能持续产生高质量的、可以委托出去的任务。这一点，即使没有 AI，也同样重要！

当下

这就是我目前的处境。

通过这段旅程，我个人在使用现代 AI 工具方面已经取得了一些成功，并且我相信我正以一种基于现实的、审慎的态度来对待它。我其实并不太在意 AI 是否会永久存在³，我是一个软件工匠，仅仅因为热爱这份事业而想要创造东西。

整个领域发展如此之快，我敢肯定我很快就会回头看这篇文章，并嘲笑自己的天真。但是，正如人们所说，如果你不为过去的自己感到尴尬，那你可能并没有在成长。我只希望自己能朝着正确的方向成长！

我在这方面并无既得利益⁴，而且不使用 AI 当然也有其他合理的理由。我完全尊重任何人的个人决定。我写这些并不是为了说服你！我只是想和那些感兴趣的人分享一下我个人使用这些新工具的方法，并大致展示我通常是如何对待新工具的，无论是否与 AI 相关。

相较于对话模型，像 Opus 和 Codex 这样的现代编程模型在训练时就被专门设计为更倾向于使用工具。 ↩︎
由于模型迭代速度极快，我必须持续修正自己对此的原有认知。 ↩︎
但最让我深感忧虑的是，这对基础不扎实的初级开发者可能造成的技能养成缺陷。 ↩︎
我不受雇于任何 AI 公司，也未进行相关投资或提供咨询服务。 ↩︎

自己免费申请美国公司 EIN

hi@rokcso.com (rokcso) — Tue, 25 Nov 2025 10:00:00 +0800

上一篇文章分享了美国怀俄明州 LLC 公司注册经验，而 EIN（Employer Identification Number，雇主识别号码）是美国公司必不可少的东西，我参考的大多数资料都是建议去 Fiverr 找人代办，会比通过 Northwest 这样的注册代理服务商代办便宜很多。

在我进一步了解之后发现其实自己申请 EIN 可能也并不复杂，整体流程就是填一张 SS-4 表格，然后传真或邮寄到 IRS（Internal Revenue Service，美国国税局）即可，并且完全免费。

在申请 EIN 之前，请确保 LLC 公司注册已获得批准，判断可以依据是否收到州政府的 Articles of Organization文件（后续公司相关信息都以这份文件上的信息为准）。不同州文件名称可能不完全一样，但通常是盖有州政府大印那份，注册代理服务商的管理后台中通常可以找到。

目前我已经完成了 Form SS-4 递交，等待 IRS 处理，这篇文章主要分享 Form SS-4 填写注意事项以及如何使用在线传真服务将填写好的 Form SS-4 传真到 IRS。

名词解释

Form SS-4

Application for Employer Identification Number，IRS 提供的用于申请 EIN 的表格。

CP 575

Initial Contact Letter - EIN Assignment Notice，在 EIN 成功申请之后，IRS 发出的通知信函，以通知、证明 EIN 已被分配，CP 575 有且仅有一份，不可重复申请、补发。

147C

EIN Verification Letter，用于验证和确认现有的 EIN 信息，在 CP 575 丢失时可以向 IRS 申请，通常可以代替 CP 575 使用。

填写 Form SS-4

在 IRS 官方网站的关于 Form SS-4 页面有提供最新 Form SS-4 PDF 文件以及详细填写说明。

使用 PDF 编辑器（比如：Smallpdf 或者 macOS 自带的预览）填写表格内容，签名部分可以使用签名工具（比如：Smallpdf）或者打印出来手写签名。

填写示例：

填写过程非常建议参考上方示例以及下面这两篇文章，仔细对照填写：

再补充一些注意事项：

4a、4b 处的地址建议填写公司注册地址，IRS 如果有文件要发给公司会寄送到这个地址（比如 CP 575 确认函），一般注册代理服务商都会提供公司注册地址以及政府文件代收并扫描上传的服务。以后报税也会用到这个地址，不确定后面开设银行账户会不会使用这个地址，但是我建议尽量保持所有地址一致（包括格式），除非是需要用于地址验证的才使用个人真实可验证的地址。

注意 11 处以及签名处的日期顺序是「月日年」，建议使用 MM/DD/YY 格式即可。

如果使用传真方式将表格递交给 IRS，则必须填写你的传真号（如何获得见下文），IRS 在分配 EIN 后会将分配的 EIN 填写到这张表格，并传真回表格中填写的传真号。

只有第一页是需要填写并回传 IRS 的，第二页是信息说明页，可以使用 Smallpdf 拆分 PDF 文件移除第二页，如果不小心回传了第二页也没关系。

填写完表格并签名之后，可以使用 Smallpdf 将公司注册成功时州政府发的 Articles of Organization 文件拼接到 Form SS-4 文件后面。

最终准备好的要递交的文件应该如上文填写示例。

传真递交 Form SS-4

可以使用在线传真服务完成这一步，但是需要注意大多数免费的在线传真服务通常只能发信不能收信，并且不会给你分配一个固定的传真号。这会导致无法接收 IRS 回传的有 EIN 的 Form SS-4。

可以使用 HelloFax 然后开通一个基础套餐的免费试用，一定要确认可以接收传真。

开通之后会得到一个固定的传真号，将这个传真号填写到上面 Form SS-4 中，并且记得设置一个取消 HelloFax 订阅的提醒事项。

一切准备就绪即可将上一步准备好的文件传真发送到 IRS，在 HelloFax 中点击左上角「发送传真」按钮，上传文件，点击「下一页」，输入 IRS 的传真号 +1 855-641-6935，点击「发送文档」。完成。

接下来就是耐心等待，不要重复发送 Form SS-4 到 IRS，如果等了很久（一个月以上）依然没有回复，可以参考 How to Get EIN Verification Letter (IRS 147C) for an LLC 联系 IRS 要求获取 EIN 验证（147C）。

如果一切正常，你的传真号会收到 IRS 回传的你的 Form SS-4（带有分配的 EIN），然后你的公司注册地址会收到 IRS 邮寄的 CP 575 确认函（一定要保存好）。

2026-02-14 更新：经过漫长（2.5 个月）的等待，我终于在今天收到了我的 CP 575，是直接邮寄到我的公司注册地址的，并没有收到 IRS 传真回传给我的带有 EIN 的 Form SS-4，中间我给 IRS 打过几次电话，都反馈没有收到我的 Form SS-4，于是只能重新传真了几次 Form SS-4 然后继续等待。

美国怀俄明州 LLC 公司注册

hi@rokcso.com (rokcso) — Mon, 24 Nov 2025 10:00:00 +0800

我注册美国公司的目的是开通 Stripe 企业版，实现更稳定的全球收款，整体流程大致会包括：1）注册美国公司；2）申请美国银行卡；3）开通 Stripe 企业版账户。我会持续记录、分享整个过程，包括后续美国公司的维护。

本文主要记录我通过 Northwest Registered Agent 注册美国怀俄明州（Wyoming）LLC 类型公司的过程，作为经验分享。

本文不会讨论注册哪个国家或地区的公司更好、用哪个注册代理服务商更好等问题，且由于注册流程或政策的变动，本文亦仅供参考。我也会在文末附上了一些我参考过的资料。

另外非常建议和 AI 配合进行注册，比如我就是和 Claude Code 一起完成注册的，过程中如果有些项目不明白怎么选怎么填，可以看看页面上有没有说明提示，也可以问问 AI（但是始终不要完全相信 AI 提供的信息）。

注册过程

访问 Northwest Registered Agent 首页，可以直接点击右上角的购物车图标（红点 1）进入注册流程，也可以点击首页的「Start an LLC」（红点 2）或者 Header 栏 Services（红点 3）里面的「Form an LLC」，不同的入口进入显示的界面有一点差异，但实际核心流程都是一致的。

本文以从购物车图标（红点 1）进入的流程为例。

Order

选择订单基本信息，首先 Business Type（红点 1）即要注册的公司类型选择 LLC，注册地（红点 2）选择 Wyoming，登记服务（红点 3）选择 Standard。

关于 Close LLC：一般不要勾选。Close LLC 是一种特殊的封闭式 LLC，所有权受到严格限制，不能自由转让，有成员数量限制，通常由少数几个紧密联系的成员（如家庭成员）拥有，适合家族企业，普通 LLC 会更灵活。

然后核对一下右侧的 Order Summary 中的费用明细：

Northwest 注册 LLC 的服务费 $39。
Registered Agent Service 即注册代理费用 $125 本次（首年）是减免的。

后续如果这个公司的 Registered Agent 依然使用 Northwest 则每年收取 $125，其实也可以选择转移到其他 Registered Agent Service 费用更低的注册代理服务商（比如 Wyoming Agents 是 $25 每年）。

WY State Fee 即 Wyoming 州注册 LLC 的州务卿登记服务费，就是刚刚选择的 Standard 登记服务的费用 $104，这个费用由 Wyoming 州政府收取。

确认无误后点击 CONTINUE。

Company

填写公司基本信息，首先输入公司名称（红点 1），可以先在 Wyoming 州政府网站 Search for Business Names/Filings 搜索确认想要注册的公司名称是否已经被注册。此处（红点 1）填写的公司名称应该带有 LLC 后缀，但是即使没有填写 LLC 后缀，实测 Northwest 在提交文件到州政府时也会帮忙更新公司名称带上 LLC 后缀。

Send Legal Notices to Attorney（红点 2）一般选择 No，除非在美国拥有律师服务。

勾选上 Use Generic Business Purpose（红点 3），表示公司业务使用通用的商业用途，如果不勾选，可以在 Business Purpose 文本框（红点 4）里补充具体业务，例如：software development, consulting, and any other lawful business. 等。

接下来公司物理地址（红点 5）和公司邮件地址（红点 6）都选择 Our Registered Agent Address 使用注册代理服务商的地址即可。

确认无误后点击 CONTINUE。

Management

填写公司管理结构和管理者信息，Management Type（红点 1）选择 Member Managed，表示公司由成员管理，适合大多数小型公司，而 Manager Managed 表示公司由成员选举的经理人管理，更适合有被动投资者的公司。

接下来填写成员信息（红点 2），此处的成员地址可以使用 Our Registered Agent Address。建议只添加一位成员，这样的 LLC 公司属于 Single-Member LLC，相比 Multi-Member LLC 在后续税务处理上会更简单。

确认无误后点击 CONTINUE。

Contact

填写公司联系人信息，Phone Number 可以使用 +86 手机号，带不带 +86 前缀都行，此处的地址信息建议使用个人真实可进行地址验证的地址。

确认无误后点击 CONTINUE。

Account

填写 Northwest 账户信息，后续需要使用这个账号、密码登录 Northwest 管理后台。

确认无误后点击 CONTINUE。

Business Identity

选择是否购买 Northwest 提供的 Business Identity 服务包，提供 90 天免费试用，后续是需要收费的，可以全部关闭。

确认无误后点击 CONTINUE。

Optional Items

选择是否购买 Northwest 提供其他服务，可以全部关闭。

特别说明一下其中 Tax ID 这项服务，是由 Northwest 代为申请 EIN（Employer Identification Number，雇主识别号码），这是注册美国公司必不可少的一项，但是几乎所有注册代理服务商的 EIN 申请服务都很贵，后续自行申请会便宜很多，甚至可以免费。

自行申请可以参考自己免费申请美国公司 EIN，其实很简单。

另外关于 BOI（Beneficial Ownership Information，实益所有权信息）申报，根据美国财政部 2025-03-02 的公告，FinCEN 发布了一项临时最终规则，取消了美国公司和美国个人向 FinCEN 申报 BOI 的要求。

确认无误后点击 CONTINUE。

Payment

最后付款即可。

如果使用的信用卡的账单地址和之前填写的公司邮件地址不一样，可能需要勾选 Credit Card Address Different From Mailing Address（红点 1）然后填写正确的信用卡账单地址，才能成功付款。

确认无误后点击 DONE。

支付成功之后刚刚 Northwest 账户信息中填写的邮箱应该会收到一封 Northwest 发来的邮件。

点击邮件中的 Go To My Account 或者 Northwest 网站上的 Login，使用刚刚 Northwest 账户信息中填写的邮箱、密码即可登录 Northwest 管理后台，可以看到公司注册订单和进度，以及可能需要根据管理后台提示做一些信息确认。

注册成功后的一些文件

我是 2025-11-21 17:50 提交的订单，2025-11-21 23:47 就已经收到 Northwest 邮件提示注册完成了，注册完成之后即可在 Wyoming 州政府网站 Search for Business Names/Filings 查到相关信息。

此时 Northwest 应该已经将公司成立相关文件上传到 Northwest 管理后台了，在管理后台的 Documents 中能看到以下三个文件：

Formation Document：组建文件/注册证书，证明该公司已经正式合法成立，包含公司名称、注册地址、注册代理人信息等。
Initial Resolution：初始决议，记录公司成立之后的首批决策，常见内容可能是任命管理人员，可以证明谁有权代表公司。
Operating Agreement：运营协议，相当于公司内部管理章程，规定公司如何运作，怀俄明州不强制要求需要此文件，但是一般都会准备。

至此，公司注册是已经完成了，但是接下来还需要申请 EIN，如果没有让注册代理服务商代办的话都需要自己操作，建议尽快（30 天之内）完成。以后每年还需要报税，我都会在自己实际做完之后更新相关文章供参考。

参考资料

Ubuntu Server 的用户系统与文件系统

hi@rokcso.com (rokcso) — Thu, 30 Oct 2025 10:00:00 +0800

最近开始使用云服务器部署一些服务，在使用过程中，我发现云服务器操作系统与日常使用的 macOS 或者 Windows 都不太一样。于是花了点时间想搞清楚这件事情。

背景：我使用的是腾讯云的新加坡服务器，安装的是 Ubuntu Server 24.04 LTS 64bit 操作系统。

什么是 Ubuntu？

Ubuntu 是基于 Debian 的 Linux 发行版。主要分为 Ubuntu Desktop 和 Ubuntu Server，前者是桌面版，面向普通个人用户，带有图形化界面，可用于日常办公、娱乐等，后者是服务器版，专为服务器环境设计，是本文主要讨论的。

Linux 是一个开源的操作系统，类似于 macOS 或者 Windows，但是日常谈论的 Linux 通常指的是 Linux 内核，内核是操作系统的核心部分，直接管理硬件资源（CPU、内存等），充当硬件和软件之间的桥梁。而 Linux 发行版则是由 Linux 内核加上一整套完整的软件组成可直接使用的操作系统，比如 Ubuntu、Debian、CentOS 等都是 Linux 发行版。

Debian 和 Ubuntu 都是 Linux 发行版，但是 Debian 是相当古老而纯粹的一个，同样是开源的，所以成为了很多其他 Linux 发行版的基础。可以理解为 Debian 在 Linux 内核的基础上提供了一些基础的软件形成了一个基础的 Linux 发行版，而 Ubuntu 又在 Debian 的基础上增加了一些更易于用户使用的软件改良后的 Linux 发行版。

而 Ubuntu Server 24.04 LTS 64bit 就是 Ubuntu 的 Server 版本，于 2024 年 4 月（24.04）发布的 LTS 版本，LTS 表示该版本会得到长期支持，通常稳定性更高，不会频繁升级，而 64bit 则是指系统架构，如今几乎所有现代服务器硬件都是 64bit 的。

用户系统

Ubuntu 的用户系统是一个以 root 超级用户为顶点，包含系统用户、普通登录用户和用户组（本文不会深入讨论）的权限管理体系。

root 用户，是系统的超级管理员，拥有至高无上的权限，可以执行任何操作，所以也是极其危险的，日常操作服务器非常不建议直接使用 root 用户进行，Ubuntu 也默认禁止通过 SSH 使用密码直接以 root 用户身份登录。

系统用户，这些用户不是给「人」登录使用的，而是给一些软件和服务使用的，遵循「最小权限原则」，可以让每个服务以独立的低权限用户身份运行。常见的系统用户包括:

www-data - Nginx/Apache Web 服务器使用的用户
mysql - MySQL 数据库服务使用的用户
redis - Redis 缓存服务使用的用户
nobody - 一个权限最小的用户，常用于需要极低权限的服务

普通登录用户，在 root 用户之下的用户，需要由具有管理员权限的用户创建、管理。普通用户只能在自己的家目录（/home/username）和系统允许的临时目录中拥有完整的读写权限，对于其他系统目录和文件通常只有读取或者完全没有权限。

日常操作服务器建议使用普通用户，需要执行更高权限的管理任务时可以通过权限提升机制（比如 sudo）来临时获取 root 权限。

用户组，是将多个用户组织在一起的机制，方便统一管理权限。每个用户至少属于一个主用户组，也可以属于多个附加用户组。常见的用户组如 sudo（该组用户可以使用 sudo 命令）、docker（该组用户可以执行 docker 命令）等。

文件系统

Ubuntu 的文件系统层次结构都是从一个唯一的根目录（/）开始的，这是整个文件系统的起点，所有其他目录和文件都位于其下。下面介绍一些常见的目录。

系统核心目录

/bin，基本用户命令的二进制文件，在现代 Ubuntu 系统中是指向 /usr/bin 的符号链接，用于存放系统中所有用户都可以执行的命令，比如 ls、cat、cp 等。

/sbin，系统管理员命令的二进制文件，在现代 Ubuntu 系统中是指向 /usr/sbin 的符号链接，用于存放系统管理员可以执行的命令，比如 ifconfig、mount、reboot 等。

/boot，启动引导程序文件，包含 Linux 内核、初始化内存盘和引导加载程序的文件，非常重要，删除会导致系统无法启动。

/dev，设备文件，包含代表硬件设备和虚拟设备的特殊文件，比如 /dev/sda 代表第一块硬盘，/dev/null 代表空设备（可以丢弃任何写入的数据）。

/etc，系统配置文件，包含系统和应用程序的配置信息，比如 /etc/passwd（用户账户信息）、/etc/hostname（主机名配置）、/etc/nginx/nginx.conf（Nginx 配置文件）等。

用户相关目录

/home，用户主目录，每个普通用户在这里都会有一个以自己用户名命名的子目录，比如 /home/ubuntu 代表 ubuntu 用户的主目录，用于存放个人文件、配置等。

/root，root 用户的主目录，用于存放 root 用户的个人文件、配置等。root 用户的主目录单独存放在根目录下，而不是 /home/root，这是为了确保即使 /home 分区出现问题，root 用户仍然可以登录系统。

程序和数据目录

/opt，可选应用软件包目录，用于存放第三方软件包，比如 /opt/redis 代表手动安装的 Redis 软件包。

/usr，用户程序和数据，包含绝大部分用户应用程序、库、文档等。这是系统中最大的目录之一。

/usr/bin，用户二进制文件，在现代 Ubuntu 系统中是实际存储用户和系统命令的地方（/bin 指向此处），比如 /usr/bin/python3 代表 Python 3 解释器。

/usr/sbin，系统管理员二进制文件，在现代 Ubuntu 系统中是实际存储系统管理命令的地方（/sbin 指向此处）。

/usr/lib，用户库文件，用于存放用户应用程序的库文件，比如 /usr/lib/python3 代表 Python 3 的库文件。

可变数据目录

/tmp，临时文件目录，用于存放临时文件，比如缓存文件、日志文件等。根据系统配置，此目录下的文件通常会在系统重启时被清除，或者定期被清理程序删除。

/var，变量数据目录，用于存放可变数据，比如 /var/log（系统和应用程序的日志文件）、/var/www（Web 服务器的网站文件）等。

用户切换

当我在云服务器后台（比如腾讯云控制台）登录时，发现登录的是 root@VM-0-7-ubuntu 这样的用户，这表明我当前是以 root 用户身份登录了主机名为 VM-0-7-ubuntu 的云服务器。

可以通过以下几种方式在用户之间切换：

su - ubuntu - 切换到 ubuntu 用户身份（可能需要输入 ubuntu 用户的密码）
sudo -i - 从普通用户切换到 root 用户环境（推荐方式，可能需要使用当前用户密码）

当我们使用 root 身份登录服务器之后，工作目录位于 /root，而使用 ubuntu 用户身份登录服务器之后，工作目录位于 /home/ubuntu。可以通过 pwd 命令确定当前所在目录。

Arclet Copier 诞生的故事

hi@rokcso.com (rokcso) — Mon, 13 Oct 2025 10:00:00 +0800

🔄 English

起点

从大约 3 年前开始，我就一直使用 Arc 浏览器作为我最主力的浏览器，即使到后期 Arc 明确不会再有功能更新，仅提供内核安全性更新，我也坚持使用了很长时间，期间间歇性尝试过 Dia（不如 Arc 那样打动我）。直到 Atlassian 宣布收购了 The Browser Company，我计划彻底放弃了使用 Arc 和 Dia，兜兜转转又回到了 Chrome。

不过始终有一个让我头疼的问题是 Chrome 无法通过快捷键复制 URL，尤其是我非常习惯使用 Arc 的 cmd+shift+C 来复制 URL，而在切换到 Chrome 后我每天至少十几次在想要复制 URL 的时候打开了 Chrome 开发者工具。

我很清楚一定有浏览器扩展程序已经解决了这个问题，但是试用了好几个，不好看、不顺手、不好用，也有可能就是我想自己写一个，于是我用 Claude Code 很快就开发好了 Arclet Copier v0.1.0，一键复制当前网页的 URL，支持配置快捷键，默认清理 URL 跟踪参数。

Arclet Copier v0.1.0

在这个过程中我感受到很强烈的创造的快乐，以及 Claude Code 的聪明，于是我开始设计更多功能：

复制 Markdown 格式
集成短链接服务
生成二维码，复制二维码
URL 清理模式切换，清理参数自定义
复制格式模板自定义
批量复制
更多……

我开始像对待一个正式产品一样对待 Arclet Copier，不断完善功能，打磨 UI/UX，上架应用商店，推广宣传。现在 Arclet Copier 已经开发到 v1.6.7 了，我设计的大部分功能都上线了，我也终于可以写下这篇文章来记录一下这段开发旅程。

Arclet Copier

我喜欢的功能

复制的稳定性

复制 URL 的成功率是 Arclet Copier 最核心的指标，一开始我使用的最常见的方案 —— 内容脚本注入（Content Script），在网页 DOM 注入一段 JavaScript 脚本来获取网页 URL 并复制到用户剪贴板。我曾经尝试过的大部分扩展程序都是这么做的，但是这有一个巨大的问题是在网页 DOM 没有准备好，或者在浏览器系统页面时，是无法成功注入脚本的，这会导致复制 URL 失败。

我想要实现一种接近于原生的复制效果，即用户在任何页面都应该能使用 Arclet Copier 成功复制 URL，这个问题把我和 Claude Code 卡了很久，最终我让 Claude Code 搜索 Chrome 最新的 API 以及广泛搜索网络内容来了解可能的解决方案。最终我们发现了 Offscreen Document API，这是 Chrome Manifest V3 引入的新 API，专门用于在后台执行需要 DOM 环境的操作。

传统的 Content Script 方案依赖于网页的 DOM 环境，这导致了三个主要问题：

DOM 准备问题：在网页 DOM 没有准备好时，无法成功注入脚本；
CSP 限制：许多网站的内容安全策略（Content Security Policy）会阻止外部脚本的执行；
系统页面限制：在 chrome:// 或 edge:// 等浏览器系统页面无法注入脚本。

而 Offscreen Document API 的工作原理是：

// 在 background service worker 中创建一个隐藏的文档
await chrome.offscreen.createDocument({
  url: 'offscreen/offscreen.html',
  reasons: ['CLIPBOARD'],
  justification: '复制文本到剪贴板'
});

// 通过消息传递将内容发送给 offscreen 文档
chrome.runtime.sendMessage({
  action: 'copy',
  text: urlToCopy
});

这个隐藏文档拥有完整的 DOM 环境和剪贴板访问权限，但不受网页 CSP 的限制，因为它运行在扩展的独立上下文中。这样一来，无论用户在什么页面，Arclet Copier 都能稳定地完成复制操作。

URL 参数清理

我设计了三种清理模式：

关闭（off）：保留所有参数，适合技术性场景
智能（smart）：只移除跟踪参数，保留功能性参数
激进（aggressive）：移除所有参数，追求最简洁的 URL

更进一步，我还允许用户自定义参数规则。你可以把某个参数标记为「跟踪参数」或「功能性参数」，系统会记住你的偏好。

自定义复制模板

一开始只提供了 URL 和 Markdown 格式的复制，但是用户的复制需求非常多样化：

有人想要 [标题](URL) 的 Markdown 格式
有人想要 标题 - URL 的纯文本格式
有人想要带时间戳的归档格式
还有人想要各种奇奇怪怪的自定义格式

于是我实现了一个模板引擎，支持一些常用变量，让用户可以自己创建模板，比如：

{{title}} 👉 {{url}}

Arc 风格的 Toast

由于我真的很喜欢 Arc 浏览器（很显然通过 Arclet 这个名字也能体现这一点），所以我在 Arclet Copier 中一些 UI 设计都有参考 Arc，想要做到 Arc 那种质感，不过很显然我没有做到，好想学会 UI 设计。

一开始我通过 Chrome 系统通知来同步 URL 复制结果，对于多屏用户，这个通知显得很烦人，用户在屏幕 A 复制网页，通知从屏幕 B 出现（因为屏幕 B 是主屏幕），所以我又通过内容脚本注入，在当前网页的右上角注入一个 Arc 风格的通知 toast，我真的很喜欢这个小 toast。

Arclet Copier Toast

但是这种方式依然受限于网页 DOM 是否准备好，在一些特殊页面（如浏览器内置页面）无法显示。我还没有找到完美的解决方案，只能先忍一忍了。😭

从个人工具到产品

最初 Arclet Copier 只是一个解决我自己痛点的小工具，但在开发过程中我逐渐将它当作一个正式产品来打磨：

国际化
主题系统
性能优化

为了保证代码质量，我还引入了（不过是在开发很后期进行的，前期主要多堆功能）：

Vitest 测试框架：覆盖核心模块的单元测试
ESLint 代码规范：保持代码风格一致
esbuild 构建工具：快速的打包和开发体验

Claude Code 协作心得

Arclet Copier 99% 以上的代码都是 Claude Code 写的，主要使用 Claude 和 GLM 的模型，整个项目开发到现在大概消耗了 5 亿 tokens，真的不算便宜。我也实践出几点建议可以分享：

单个对话主题要集中：避免在一个上下文环境中开发完全没有关联的不同功能，会给 AI 造成干扰。但是可以开多个对话同时进行不同功能开发。
使用 \init 命令创建 CLAUDE.md：完成一个阶段的开发或者功能设计后，让 AI 沉淀文档到项目中。这个 CLAUDE.md 会在后续对话中作为项目说明，有助于 AI 快速了解项目架构。
善用网络搜索：面对复杂问题、多次尝试解决不了的问题，直接让 AI 主动进行网络搜索。比如 Offscreen API 就是通过搜索最新的 Chrome 文档找到的。
先分析，再动手：让 AI 先分析问题，提供解决方案给你确认，然后再让 AI 进行开发。这样可以避免走弯路。
大任务拆解 TODO：对于大型任务，可以让 AI 创建一个 TODO List 给你确认，然后再让 AI 一边开发一边更新 TODO List，直到所有任务完成。
保持代码审查意识：虽然 AI 写的代码大部分时候都很好，但还是要 review 一下，尤其是涉及安全、性能的关键部分。可以另起一个对话让 AI 来 review。

另外：

Arclet Copier 已经上架了 Chrome Web Store 和 Edge Add-ons，完全免费，更多信息可访问官网了解。

欢迎下载使用，有任何 Bug 反馈或功能建议请通过 GitHub Issues 或邮件联系我。如果觉得有用，不妨给项目点个 Star ⭐️ 或者在应用商店留个五星好评。❤️

The Story of Arclet Copier

hi@rokcso.com (rokcso) — Mon, 13 Oct 2025 10:00:00 +0800

🔄 简体中文

Starting Point

Starting about 3 years ago, I have been using the Arc browser as my main browser. Even when Arc later made it clear that there would be no more feature updates and only kernel security updates, I persisted in using it for a long time, intermittently trying Dia during this period (which didn’t impress me as much as Arc). Until Atlassian announced the acquisition of The Browser Company, I planned to completely abandon using Arc and Dia, and after going around in circles, I returned to Chrome.

However, there was always a problem that gave me a headache: Chrome couldn’t copy URLs via keyboard shortcuts. I was especially used to using Arc’s cmd+shift+C to copy URLs, and after switching to Chrome, I would open Chrome Developer Tools at least a dozen times daily when I wanted to copy URLs.

I was well aware that there must be browser extensions that had already solved this problem, but after trying several, they were either ugly, clunky, or hard to use. It’s also possible that I just wanted to write one myself, so I quickly developed Arclet Copier v0.1.0 using Claude Code - one-click copying of the current webpage’s URL, supporting configurable shortcuts, and cleaning URL tracking parameters by default.

Arclet Copier v0.1.0

During this process, I felt a strong joy of creation, as well as Claude Code’s intelligence, so I began designing more features:

Copy Markdown format
Integrate URL shortening services
Generate QR codes, copy QR codes
URL cleaning mode switching, custom cleaning parameters
Custom copy format templates
Batch copying
More…

I began treating Arclet Copier like a formal product, continuously improving features, polishing UI/UX, listing it on app stores, and promoting it. Now Arclet Copier has been developed to v1.6.7, most of the features I designed have been launched, and I can finally write this article to record this development journey.

Arclet Copier

Features I Love

Copy Reliability

The success rate of copying URLs is Arclet Copier’s most core metric. Initially, I used the most common solution - Content Script Injection, injecting a JavaScript script into the webpage DOM to get the webpage URL and copy it to the user’s clipboard. Most extensions I had tried used this approach, but this has a huge problem: when the webpage DOM is not ready, or on browser system pages, the script cannot be successfully injected, causing URL copying to fail.

I wanted to achieve a near-native copying effect, where users should be able to successfully copy URLs using Arclet Copier on any page. This problem stumped Claude Code and me for a long time. Eventually, I had Claude Code search Chrome’s latest APIs and extensively search web content to understand possible solutions. Finally, we discovered the Offscreen Document API, which is a new API introduced in Chrome Manifest V3, specifically designed for performing operations that require a DOM environment in the background.

The traditional Content Script approach relies on the webpage’s DOM environment, which leads to three main problems:

DOM readiness issues: When the webpage DOM is not ready, scripts cannot be successfully injected;
CSP restrictions: Many websites’ Content Security Policy blocks external script execution;
System page limitations: Scripts cannot be injected on browser system pages like chrome:// or edge://.

The Offscreen Document API works by:

// Create a hidden document in the background service worker
await chrome.offscreen.createDocument({
  url: 'offscreen/offscreen.html',
  reasons: ['CLIPBOARD'],
  justification: 'Copy text to clipboard'
});

// Send content to the offscreen document via message passing
chrome.runtime.sendMessage({
  action: 'copy',
  text: urlToCopy
});

This hidden document has complete DOM environment and clipboard access permissions, but is not restricted by webpage CSP because it runs in the extension’s independent context. This way, regardless of what page the user is on, Arclet Copier can stably complete copy operations.

URL Parameter Cleaning

I designed three cleaning modes:

Off: Keep all parameters, suitable for technical scenarios
Smart: Only remove tracking parameters, keep functional parameters
Aggressive: Remove all parameters, pursuing the cleanest URL

Furthermore, I also allow users to customize parameter rules. You can mark a parameter as a “tracking parameter” or “functional parameter,” and the system will remember your preferences.

Custom Copy Templates

Initially, only URL and Markdown format copying was provided, but users’ copying needs are very diverse:

Some want [title](URL) Markdown format
Some want title - URL plain text format
Some want archived format with timestamps
Others want various strange custom formats

So I implemented a template engine that supports some common variables, allowing users to create their own templates, such as:

{{title}} 👉 {{url}}

Arc-style Toast

Since I really love the Arc browser (obviously reflected in the name Arclet), some UI designs in Arclet Copier reference Arc, wanting to achieve that Arc-like quality, though obviously I didn’t achieve it. I really want to learn UI design.

Initially, I synchronized URL copy results through Chrome system notifications. For multi-screen users, this notification was very annoying - users copy webpages on screen A, but notifications appear from screen B (because screen B is the main screen). So I used content script injection again to inject an Arc-style notification toast in the top-right corner of the current webpage. I really love this little toast.

Arclet Copier Toast

But this approach is still limited by whether the webpage DOM is ready and cannot display on some special pages (like browser built-in pages). I haven’t found a perfect solution yet, so I have to bear with it for now. 😭

From Personal Tool to Product

Initially, Arclet Copier was just a small tool to solve my own pain points, but during development, I gradually treated it as a formal product to polish:

Internationalization
Theme system
Performance optimization

To ensure code quality, I also introduced (though this was done quite late in development, early stages mainly focused on piling up features):

Vitest testing framework: unit test coverage for core modules
ESLint code standards: maintaining consistent code style
esbuild build tool: fast packaging and development experience

Claude Code Collaboration Insights

Over 99% of Arclet Copier’s code was written by Claude Code, mainly using Claude and GLM models. The entire project development has consumed about 500 million tokens so far, which really isn’t cheap. I’ve also practiced several suggestions I can share:

Keep single conversation topics focused: Avoid developing completely unrelated different features in one context environment, which will interfere with AI. But you can open multiple conversations to develop different features simultaneously.
Use \init command to create CLAUDE.md: After completing a development phase or feature design, have AI consolidate documentation into the project. This CLAUDE.md will serve as project documentation in subsequent conversations, helping AI quickly understand project architecture.
Make good use of web search: For complex problems or issues that can’t be solved after multiple attempts, directly have AI proactively conduct web searches. For example, the Offscreen API was found by searching the latest Chrome documentation.
Analyze first, then act: Have AI analyze problems first and provide solutions for your confirmation, then have AI proceed with development. This can avoid taking detours.
Break down large tasks into TODOs: For large tasks, you can have AI create a TODO List for your confirmation, then have AI develop while updating the TODO List until all tasks are completed.
Maintain code review awareness: Although AI-written code is usually good most of the time, you should still review it, especially critical parts involving security and performance. You can start another conversation to have AI review it.

Additionally:

Arclet Copier has been listed on Chrome Web Store and Edge Add-ons, completely free. For more information, visit the official website.

Welcome to download and use it. For any bug reports or feature suggestions, please contact me through GitHub Issues or email. If you find it useful, feel free to give the project a Star ⭐️ or leave a five-star review on the app store. ❤️

个人开发的 GitHub 工作流

hi@rokcso.com (rokcso) — Tue, 09 Sep 2025 10:00:00 +0800

前段时间复习了一些 Git 常用命令，目的是希望自己即使是一个人维护项目也可以更科学、更标准化一点，经过一段时间的实践，我个人开发的 GitHub 简易工作流基本成形。

这套工作流不适合所有人，PR 流程的引入增加了流程的复杂度。

初始化项目

先本地新建项目，需要同步 GitHub 时再创建远程仓库然后关联：

git remote add origin git@github.com:username/repository_name.git

首次 push main 分支时需要使用 -u 参数指定远程分支：

git push -u origin main

之后 main 分支的 push 一律使用：

git push origin main
# 或者
git push

在配合 AI 编程的时候，有意识的多次 add，当项目内容有一个逻辑上最小完整功能时再 commit 一次，并且使用简短明了有意义的 commit 描述。

分支管理

一般只用到 main 分支和 dev 分支，在本地新建 dev 分支：

git switch -c dev

然后进行新的开发，当需要将 dev 上的开发成果合并到 main 分支时，再 push dev 分支到 GitHub：

git push -u origin dev

在 GitHub 上通过 PR（Pull Request）进行分支合并，以便进行代码审查，使用「Squash and merge」方式完成合并。这种方式会将 dev 分支上本次 PR 的所有 commit 记录压缩为一条新的 commit 合并到 main 分支上。

最终效果是 main 分支上会新增一条对应这次合并的 commit 记录，dev 分支上的 commit 记录则保持原样（同本地一致）。

此时本地 main 分支落后于远程 main 分支一个 commit，需要在本地 main 分支上拉取最新的远程 main 分支：

git switch main
git pull origin main

再继续进行其他新的开发时，切换到 dev 分支并将 dev 分支变基到最新的 main 分支上。

git switch dev
git rebase main

当新的开发成果需要被合并到 main 分支时，再次 push 本地 dev 分支到远程 dev 分支，此时由于本地 dev 分支是基于上一次合并后产生的新的 commit 开始的，与上一次合并后的远程 dev 分支不一致，所以本次 push 可能需要强制覆盖远程 dev 分支：

git push --force-with-lease origin dev

在 GitHub 上通过 PR 进行分支合并。完整流程就是这样，后续以此循环即可。

如果不想使用 PR 则完全可以在本地完成分支合并，只 push main 分支到远程仓库。