公开仓库不是私有工作区的压缩包#

很多技术分享会卡在第一步：本地确实有一套能跑的流程，但里面混着路径、日志、工具配置、工艺名称、版图或仿真中间成果。直接公开不合适，完全不公开又失去交流价值。

这个仓库没有追求复刻私有流程，而是把目录、接口和检查方式整理成外部能看的样子。

它保留的是这些东西：

• PDK 无关的脚本和参数转换思路。
• 用占位符表达的设计输入。
• Virtuoso bridge 的组织和调用形态。
• 可公开的 Codex skill 说明。
• 对上游开源桥接项目的指针。
• 发布前范围检查脚本。

它明确不保留的则是本地工艺、模型、规则、数据库、仿真输出和机器环境细节。这样的仓库不会让外部读者一键复现你的私有环境，但能让别人看懂“这类流程应该怎样拆”。

这比把所有内容压成一个模糊的示例更有用。工程经验能公开的部分，往往不只是结果文件，还包括接口、目录和检查方式。

先写 non-goals，后写 goals#

这个仓库的 README 很早就列出了 non-goals：不分发 PDK、模型、规则、signoff 数据，不替代厂商或 foundry 支持，不公开私有原理图、版图、提取结果或测量证据。

这件事看似只是合规文字，其实会直接影响后面的目录设计。

如果目标是“公开完整工程”，目录会自然走向大而全：原始库、仿真结果、报告、环境脚本都想放进去。可一旦先承认这些不是公开目标，仓库就会变成另一种形态：它只保留能解释控制模式的最小材料，把真实执行留在使用者自己的授权环境中。

这种写法对 EDA 项目尤其重要。EDA 自动化流程麻烦的地方，常常是代码背后连着 PDK、许可证、模型和本地环境。先写清楚 non-goals，可以避免仓库在后续维护里一点点滑向“看起来方便但不该公开”的状态。

子模块也是索引#

仓库里把 virtuoso-cli、skillbridge、virtuoso-bridge-lite、via 作为桥接工具指针，而不是把所有上游内容复制到一起。

这个选择有两个好处。

第一，它让公共工作区更像索引。读者能看到这套 Virtuoso 自动化生态里有哪些工具、各自大概承担什么角色，但不需要这个仓库成为所有工具历史的混合体。

第二，它把维护责任分开。公开仓库自己维护的是文档、样例、skill 和检查脚本；桥接工具仍然保留各自的上游许可证、历史和发布节奏。

这对长期维护很关键。一个公开样例仓库如果把太多第三方或上游内容直接揉进来，后续更新会变得很痛苦，也容易让读者误解所有内容都属于同一个发布包。

占位样例比脱敏结果更稳#

仓库里保留了一个 sanitized operation example：把一个小的设计参数 JSON 转成 virtuoso-cli schematic build spec。这个例子的重点不是某个真实器件参数，而是控制路径：

1
design input -> conversion script -> vcli build spec -> local Virtuoso bridge

这里最值得学的是“占位样例”的思路。

脱敏结果常常有一个问题：你以为删掉了敏感字段，但上下文仍可能暴露内部约定。占位样例更保守，它从一开始就只表达结构，不表达真实私有数据。读者可以看到输入长什么样、输出要服务哪个 CLI、脚本怎样组织，但不会拿到具体的私有工艺证据。

对博客写作也是一样。写 EDA 自动化经验时，不一定要贴真实项目截图或日志。很多时候，公开一个简化输入、说明转换步骤、解释校验点，已经足够让读者理解方法。

校验脚本要进入日常流程#

这个仓库有一个 check_public_boundary.sh，用来拦截典型的私有路径、许可证环境变量、私有器件名、密钥片段，以及不该跟踪的 EDA 成果后缀。

脚本本身不复杂，但它的定位很正确：自动检查不是法律审查，也不能替代人工判断；它是日常开发里的防线。

这类防线应该尽早存在。原因很简单：公开仓库维护到后面，新增文件通常很碎，可能是一段文档、一份小 JSON、一个脚本、一次修复。靠每次都完整人工回看，很容易漏。把常见错误做成脚本，至少能在提交前挡住一批低级问题。

这也给这个博客自己的发布流程一个提醒：安全扫描、草稿审计、封面检查、构建和生产草稿泄漏检查，应该被串成一条命令，而不是靠发布当天临时想起来。

文档要告诉别人如何安全提问#

公开 EDA 仓库还有一个隐性问题：别人可能在 issue 或 PR 里贴出不该贴的材料。

所以仓库里不只需要 README，还需要贡献说明、支持说明、安全策略、维护者指南和 publication boundary。这些文档不是摆设，贡献者看完应该知道哪些内容能发 issue，哪些材料必须换成自己的授权环境。

这类文档对小项目也值得记。尤其是当项目涉及课程资料、实验环境、内部服务、EDA 工具链或本地自动化时，贡献规则可以减少很多后续清理成本。

一个公共仓库越是贴近真实工程，越需要把“哪些东西不该公开”写明白。

公开样例不能替代授权环境#

EDA 自动化分享经常会被误读成“给我一套环境就能跑”。不过真实情况不是这样。大多数 Virtuoso 相关流程都依赖使用者自己的授权工具、工艺包和项目环境。

codex_virtuoso_workspace_public 的价值在于它没有假装这些前提不存在。它把公共部分放到仓库里，把私有执行留给本地授权环境，把桥接工具作为可替换入口，把样例做成结构演示。

这样写清楚之后，读者不会误以为这个仓库能替他们解决授权工具和工艺环境。

它不承诺一键复现私有工程，但把几件可复用的做法留得很清楚：

• 如何把本地流程拆成公共控制模式和私有执行环境。
• 如何用子模块或指针组织桥接工具。
• 如何用占位输入表达数据结构。
• 如何写清楚哪些材料不能提交。
• 如何把检查脚本纳入维护习惯。

我自己的发布边界#

这个仓库也反过来影响了我整理博客内容的方式。

我想写项目回看、课程实验和日常工程故事，但这些素材很多来自本地工作区。直接把过程全部公开并不合适；完全不写又浪费了很多可复用经验。

更合理的做法是：

• 只写公开可解释的方法论和架构取舍。
• 给能公开的 GitHub 仓库加 source 链接。
• 对本地项目只写抽象后的工程经验，不写路径、人员、内部标识和原始消息。
• 长文统一配本地封面，先进入草稿。
• 发布前跑安全扫描和生产泄漏检查。

这样博客就不会变成“项目截图堆放处”，而是一个先处理公开范围、再写工程经验的笔记库。

公开前先把范围拆出来#

整理这类经验时，我会先列清楚三件事：能公开的材料、必须删掉的材料、只能让读者在自己授权环境里替换的部分。

codex_virtuoso_workspace_public 这个仓库的重点正在这里：它把公开说明、占位样例、子模块索引、公共 skill 和校验脚本放在同一个工作区里，让分享变得可维护。

半私有、半公开的工程项目也可以这么处理：别搬原始工作区，先把能公开的做法、样例和检查流程拆出来。