脚本管得明白
把散装脚本、定时任务和人工命令收成统一入口，不再靠人记路径和口口相传。
ExecGov
执治
以 Python 脚本为第一种成熟执行资产，Web 端已支持 Python / Shell 脚本接入，帮你把团队里那些散装的、危险的脚本管得明明白白。谁、在什么时候、执行了什么、结果如何，全都有记录。
执治
以 Python 脚本为第一种成熟执行资产，Web 端已支持 Python / Shell 脚本接入，帮你把团队里那些散装的、危险的脚本管得明明白白。谁、在什么时候、执行了什么、结果如何，全都有记录。
我们正在寻找首批标杆共创客户。如果你正受困于 AI 落地过程中的管控、审计、集成或本地接入难题，欢迎继续沟通，一起把下一代企业智能工作流定义清楚。
Brand Signal
帮你把团队里那些散装的、危险的脚本，管得明明白白。谁、在什么时候、执行了什么、结果如何，全都有记录；出了问题，也能追得回来。
ExecGov（执治）是一个以 Python 脚本为第一种成熟执行资产的多租户能力治理与执行平台。
名字里的 Exec 来自 Execution，Gov 来自 Governance。 这里说的不是政府项目，而是强调 AI、脚本、本地资源和线上能力都要在治理边界内执行。 如果能力不能在规则里真正落地执行，就不是 ExecGov 想解决的问题。
很多团队其实并不缺脚本，缺的是 统一入口、权限边界、执行确认和结果留痕。 脚本散在个人电脑、共享盘、服务器和聊天记录里，谁能跑、什么时候跑、跑完结果在哪里，常常没人说得清。
ExecGov 当前先把最常见、也最通用的一类能力，也就是 Python 脚本，做成可接入、可审计、可交付的第一条链路。 你可以先从公开体验入口走完一条简化流程，再决定是否接入自己的真实场景。
当前 Web 上传注册入口已经统一支持 Python / Shell 文本脚本；公开体验页固定展示 左侧 Python `task_brief_demo.py` + 右侧 Shell `clean_log_demo.sh`， 真实体验脚本来自 exec-gov-ai-skill-platform-script/tenant_1000/experience/， 由 manifest 做热插拔映射。
当前已经完成第一轮兼容式升级：平台新增了通用资源层和执行器注册层，第一种非脚本能力样板 HTTP 能力接入 已先在 public 超管 侧落地，用来验证“资源模型 + 执行器 + 审计链路”这条新路径。 当前租户侧只开放只读台账，用于查看自己已获授权的 HTTP 资源摘要、鉴权方式和写边界； 配置、凭据治理和试跑仍然只放在 public 超管治理域。 这并不意味着平台已经对租户开放通用 API 自助接入；现阶段更高优先级仍然是把 1.1 自动注册、支付、续费和停开恢复 做成低客服闭环。
这条 1.1 路线已经先落到 public 超管 侧：订单创建、确认支付、开通 / 续费、续费提醒扫描、到期停开扫描都会回写客户与租户状态。 但这并不等于终端用户已经可以完整自助支付。真实第三方支付网关、用户账单中心和外发提醒渠道仍在后续阶段。
同时，标准 SaaS 共享租户前端骨架也已经建立：从 tenant_1003+ 开始，标准 SaaS 客户不再默认一客户复制一套前端工程， 而是优先走共享租户前端。它当前已经能承接正式租户入口，但品牌化、初始化和更细菜单边界仍在继续收口。
无论你是个人开发者、团队负责人还是企业 IT 管理者，这里都会先告诉你 它能帮你解决什么问题、适合先走哪条入口，以及 下一步怎么开始最省力。
从免登录体验到设计合作伙伴，再到真实接入，这套入口设计的目标都是让你先确认“脚本能不能被管住、跑稳、留痕”，再决定如何落地。
Platform Thesis
ExecGov 的项目层定位是 An Open & Secure AI Agent Execution Layer。 落到产品层，它对外呈现为“ExecGov（执治）”。它真正想解决的，不是聊天体验，而是 真实任务如何在规则里被稳定执行。
对当前官网口径来说，最稳的理解方式是三层： 底座层 负责多租户、安全、权限和审计， 抽象层 用 Skill 表达能力单元， 实现层 当前以 Python 脚本为主，并开始用 HTTP 资源样板验证第二种能力接入方式。
这轮也进一步收紧了权限边界： 白名单租户 admin 只保留最小跨租户控制台入口， 不会看到 HTTP 能力接入 这类平台治理页； 同时运行时与菜单侧也不再使用 user_id == 1 这类不安全条件来误判管理员。
从商业化主线看，当前最实际的进度不是“已经做成完整 SaaS 收费台”，而是“已经先把平台运营侧的收费与生命周期骨架跑起来”；用户自助链路仍在继续补齐。
对正式客户来说，当前已经不是只有“一客户一套前端代码副本”这一条路。标准 SaaS 客户可以先走共享租户前端； 如果需要更强隔离、专属页面、专属品牌或更深部署控制，再继续走单租户交付或私有化。
关键动作先确认，再执行，避免 AI 直接越权操作。
从输入到结果都能留痕复盘，方便治理与合规要求落地。
脚本、内网 API 和私有资源都可以逐步纳入统一入口。
从免费线到本地脚本位、标准团队版，再到企业部署，逐步扩展而非推倒重来。
Commercial Route
当前更稳的理解方式不是笼统地说“先体验再看”，而是先判断自己属于 免费线、 本地脚本位扩容、 标准团队版， 还是 企业交付。
无需先理解复杂架构，先体验一句话调度脚本，再判断这种方式是否值得正式接入自己的执行流。
先判断自己是只需要个人空间继续扩容，还是已经进入标准团队协作；多人协作优先看共享 SaaS 正式租户路径。
优先判断私有化、内网接入、数据安全和合规要求能否落地，再决定要不要进入正式部署和交付。
Showroom
这些案例不是为了展示一个按钮能点通，而是为了展示 ExecGov 如何把复杂、危险、容易出岔子的脚本流程， 变成 可申请、可确认、可执行、可回看的服务。
Best Fit
现在不适合把战线铺得太开。对一个单人持续推进的平台来说，先把最容易成交、最容易复用、最贴近现有代码能力的三类客户做深更重要。
适合已经有大量表格、报表、抓取、清洗、导入导出脚本，但入口分散、执行混乱、结果难追踪的团队。
适合要做日志清理、巡检、批量处理、定时报表、脚本治理和执行留痕的技术与运维团队。
适合对租户隔离、权限边界、内网环境和私有部署有明确要求，但又不想一开始就采购重系统的正式客户。
Brand Position
对外统一使用 ExecGov（执治） 这一套品牌，不再区分“项目名”和“产品名”两套说法； 代码仓库 slug 和现有技术标识暂时保留历史命名。
定位：企业级 AI 执行与治理平台
Slogan：让每次自动化，都可靠且可控。
用于官网、资料页、方案、合同和正式交付沟通。
当前策略：先把脚本型能力做稳，再逐步扩到 API、模板、连接器和审批流。
命名说明：ExecGov = Execution + Governance，其中 Gov 指的是治理，不是政府项目。
当前状态：exec-gov-ai-skill-platform 主仓库 slug 已完成统一；execgov-cli/ 目录路径仍保留历史命名，但 CLI 对外命令已统一为 execgov-cli。
Founder Note
我现在在杭州，以微创业方式继续把这件事往前做。我的长期主线是 8 年前端交付，最近 2 年 持续补强 Python 自动化和小型全栈闭环。 核心目标不是讲一个很大的平台故事，而是把过去交付里反复碰到的 脚本接入、权限边界、执行留痕 和 本地桥接 这些问题，尽量做成真正能帮人省时间、减少返工的产品。
如果要把这件事再收成一句话，就是： 先把平台做成一个能持续解决真实问题、也能支撑稳定经营的小生意。
现在不是融资驱动的大项目，而是先靠解决真实问题，把平台一步步做成可以独立养活自己的生意。
长期主线是前端、GIS 可视化和中后台，最近两年持续补强 Python 自动化与小型全栈闭环。
当前先把网页入口和本地接入这条线做通，其他更远的能力暂时不讲太满。
先走免费线，再按本地脚本位、标准团队版和企业交付逐步推进，不把所有人都塞进同一条路。
Execution Flow
先理解任务，再给出执行计划，而不是直接越权调用底层能力。
把脚本、Skill、模板和后续能力包组织成正式目录，并受权限和规则控制。
关键动作需要确认，当前重点是把云端和本地这两种执行位置讲清楚。
从结果产出到日志和审计，平台强调可追踪，而不是一次性跑完就结束。
Delivery Toolkit
这组内容面向已经准备推进真实项目的访客， 重点是把文件链路、交付物和接入准备一次说清楚。
Who It Fits
需要一个客户一个租户、一个交付入口、可持续扩展多客户，而不是把所有客户混在一个后台里。
需要统一管理模板、公告、审计、客户台账和版本回滚，同时保持租户边界清晰。
需要把已有脚本整理成可调用、可描述、可维护的能力，并在免费入口、共享 SaaS 或本地执行路径之间找到合适的起步方式。
Deployment Modes
面向需要更强隔离、专属页面、专属品牌或更深部署控制的企业客户，一个客户一个租户，一个入口，一套可持续维护的能力边界。
从 tenant_1003+ 开始，标准 SaaS 客户优先进入共享租户前端。共享的是正式发版节奏，不共享租户数据、权限和结果。
统一管理租户、模板、公告和日志，同时保持不同客户之间的隔离边界清晰。
面向个人用户和小团队提供低门槛体验与升级入口。
当前重点覆盖本地环境与 CLI 桥接，适合需要连接本地脚本和内网资源的场景。
Roadmap
当前路线分为两步：先把交付、体验和接入链路做稳，再继续扩展协作、能力类型和产品化支持。
先把客户交付、公开体验、个人入口和 CLI 最小链路做成真实可用的东西。
小团队协作、额度套餐和更通用的能力接入，会在下一阶段持续完善。
先把入口、角色和阅读路径对齐，避免一开始就在各页之间来回跳转。
Quick Start快速开始用最短时间看懂如何从免费线开始、如何接脚本，以及何时该走团队版或企业路径。
FAQ常见问题把定位、安全边界、本地接入和当前适合谁一次讲清楚。
Product产品概览先理解平台在做什么，不在做什么，以及当前最准确的公开定义。
Capabilities核心能力多租户、可信执行、模板分发、公告治理和 CLI 桥接能力一页看清。
CLICLI 指引直接看本地登录、能力接入、Skill 执行和 Agent 骨架现在到底做到哪一步。
Delivery客户流程 / 交付单独看客户怎么使用平台、平台怎么交付，以及脚本热更新如何形成正式闭环。
Billing支付与会员单独看个人免费页怎么付款、团队版月租 / 年租怎么注册，以及当前支付这条线已经完成到哪。
Files文件上传 / 结果下载适合文件型任务、报表结果和需要下载产物的项目，不再把“结果只是一段文本”当默认前提。
Deliverables交付物 / 文档入口把客户最终拿到的入口、说明和结果物单独讲清楚，方便交付和后续使用。
Checklist客户接入准备清单适合已经准备真实脚本型能力和真实场景的人，先把接入资料补完整，再继续推进团队版或企业交付。
Materials介绍资料把平台介绍、价值表达和介绍提纲单独整理，便于阅读、评审和方案沟通。