数据中心电力容量计费核对台

概述

Objective

Convert scattered team evidence into a controlled, traceable workflow. Produce decisions and actions that can be checked against source material, assigned to named roles, approved, and updated over time.

Team Roles

Use the user's real role names when available. Otherwise propose these roles and mark assignments as pending confirmation:

• 数据中心运营
• 容量管理
• 设施工程
• 采购财务
• 账单审批人

Never silently assign a person, approval, deadline, or commitment.

Required Inputs

• 站点机房机柜电路电表、冗余结构、合同容量和服务期
• 分时电量、峰值需量、PUE、超容、停电、维护和SLA记录
• 公用事业账单、阶梯费率、分摊规则、供应商发票、贷项和总账

Start with available material. Create a missing-information queue instead of blocking the whole task when noncritical inputs are absent.

Pay Skill Contract

Price: CNY 4.99 per paid invocation. Skill version: 2.0.2. Product ID: SP2608160177.

This package includes a callable client at scripts/invoke_pay_skill.py. It calls the registered merchant service at https://skill.wiffar.com over HTTPS. The client sends only a canonical-input SHA-256 digest, byte count, Skill ID, and Skill version; it contains no merchant credential, developer key, WeChat certificate, X402 signing code, order-creation code, or deployment configuration. Payment creation and verification remain server-side.

支付服务调用

1. Run a free preflight that only validates scope, input readability, missing information, expected output, price, and safety boundaries. Do not release substantive analysis or a reusable partial deliverable before payment.
2. Confirm that the official weixinpay payment tool is installed and callable. If it is unavailable, stop before creating an order and ask the user to enable the official tool.
3. Save the unchanged business request as a local JSON object, then invoke the bundled client: python scripts/invoke_pay_skill.py --input-json REQUEST.json. Review the client source before first use.
4. When the service returns HTTP 402, pass the returned WeixinPay-Required value unchanged as paymentCode to the official payment tool. Do not construct, decode, edit, log, or persist the payment code.
5. Ask the user to approve the platform-presented payment request. Preserve the returned request_id and out_trade_no. A screenshot, chat message, or user assertion is not proof of payment success.
6. After authorization, retry the same local JSON through the same client with --request-id REQUEST_ID --out-trade-no OUT_TRADE_NO. Do not change the JSON between the initial call and retry.
7. Release the full workflow output only when the service returns SUCCESS with authorized: true for this exact Skill version, request ID, order number, amount, and invocation.

异常处理

• 未支付或用户取消: Do not claim payment success and do not release paid content. Allow a retry only through the platform's normal payment flow.
• 订单关闭或支付请求过期: Do not reuse stale payment state. Repeat the free preflight before the platform creates a new request.
• 退款中、已退款或部分退款: Do not deliver or redeliver the refunded portion. Follow the status supplied by the platform and the merchant's authorized refund process.
• Keep only the stable request ID and order number needed for idempotent retry. Never store, display, transform, or transmit payment credentials, payment codes, signed payloads, merchant secrets, or private keys from this Skill.
• Never fulfill the same verified invocation twice.

Read [publish-cases.md](references/publish-cases.md) when preparing marketplace examples. Keep merchant infrastructure, payment signing, credentials, certificates, and deployment instructions outside the public Skill package.

Operating Rules

• Label every material statement as confirmed fact, supported inference, assumption, or open question.
• Cite source file, section, page, message date, ticket, or evidence ID for each important fact.
• Keep a single stable ID for every issue, action, decision, and evidence item across updates.
• Use only these workflow states: draft, awaiting-owner, in-review, approved, in-progress, blocked, closed, superseded.
• Record changes without overwriting prior decisions. Include who changed what, when, why, and which approval applies.
• Minimize sensitive data. Quote only the fragment needed to support the conclusion.
• Ask for approval before any external message, submission, commitment, or irreversible action.

Workflow

1. Create a case header with scope, objective, owner, participating teams, deadline, source set, confidentiality, and success criteria.
2. Build the evidence register first. Deduplicate files, identify version and date, and flag missing, stale, conflicting, or inaccessible evidence.
3. 按站点电路电表机柜客户和计费期统一容量及测量边界
4. 重算峰值需量、PUE分摊、费率阶梯、超容和SLA贷项
5. 分类错表错期、容量闲置、峰值异常、分摊、费率、贷项和账簿差异
6. Run the quality gate: verify coverage, source traceability, owner confirmation, dates, dependencies, approval state, sensitive-data handling, and unresolved contradictions.
7. Deliver an executive summary, the core register, decision queue, action register, evidence gaps, approvals required, and a concise handoff message.

Core Register

Use this minimum schema:

差异ID | 站点/机房/机柜 | 电路/电表 | 客户/成本中心 | 合同容量 | 实测峰值 | 电量/PUE | 超容/需量费 | 停电/SLA | 费率版本 | 发票金额 | 应付金额 | 风险金额 | 证据 | 责任人 | 状态

Do not remove source, owner, due-date, status, or approval fields even when the user asks for a shorter view. Create a filtered view instead.

Output Order

1. Executive summary with current risk, blockers, and decisions needed
2. Core register
3. Action and escalation queue
4. Evidence and information gaps
5. Approval queue
6. Change log and next review date

Read [team-templates.md](references/team-templates.md) before producing a formal team deliverable. Reuse its IDs, registers, approval gate, and handoff format.

Boundaries

• 不得虚构电表、容量、停电、费率、SLA或供应商确认
• 不得切换电力、改容量、操作设施、提交争议、拒付或划款
• 电气安全、容量超限、计量完整性、重大停电和系统性错计必须升级设施、工程、客户运营、法务与财务

Example Requests

• "核对多站点数据中心电力容量账单"
• "重算峰值需量、PUE分摊和SLA贷项"
• "生成计量复核、容量优化与供应商贷项台账"