开云体育改办法还仅仅改文档的事-开云(中国)Kaiyun·官方网站 - 登录入口
发布日期:2026-08-28 07:34    点击次数:110

开云体育改办法还仅仅改文档的事-开云(中国)Kaiyun·官方网站 - 登录入口

本文编译自 Anthropic 官方博客《The AI-Native SDLC Playbook》开云体育,2026 年 8 月 21 日发布,作家 Louis Claxton。全文约八千字,保留了原文全部代码示例和设立样板,对部分章节作念了稳当汉文读者的表述颐养

这里的 SDLC 指的是「软件迷惑生命周期」全称:Software Development Life Cycle,说的是软件从一个思法形成线上居品的完竣过程,平时拆成筹谋、想象、构建、测试、部署、运维六个阶段

在看著作之前,先看一下这个数据:App Store 销售额十年来初度下跌

换言之:香草时间,完了了

SDLC(Software Development Life Cycle,软件迷惑生命周期)说的是软件从一个思法形成线上居品的完竣过程,平时拆成筹谋、想象、构建、测试、部署、运维六个阶段

01 代码不再是瓶颈

许多团队照旧在用 AI 写代码了,速率快到一年前压根思不到。但代码周围的过程没跟上

大部单干程团队如故老一套审批门禁、代码审查、东谈主工叮嘱、合规战略,把 Claude Code 这类 agentic coding 器具带来的效用进步活活卡住

传统作念法里,SDLC 的每个阶段是一个寂寥关节,各有各的负责东谈主。居品司理写需求,时期架构师把需求形成想象,工程师按想象写代码,QA(Quality Assurance,质料保证)团队作念考证,发布团队负责上线,运维团队盯线上。责任在这些关节之间流转,靠的是文档、工单和签批

这套过程很重,是为了确保每一步都有东谈主负责、有东谈主宰控。但它的想象前提是:写代码和实现代码是最耗时、最花钱的阶段。当今这个前提不树立了。PRD(Product Requirements Document,居品需求文档)、估时会议、居品安全审查,这些东西存在的真理是在可能长达数周、数月致使数个季度的迷惑周期里强制对皆判辨

传统 SDLC 还有一个假定:每一步都是东谈主在作念。产出最大的那些组织照旧围绕 agentic AI 的智商重建了过程,同期确保东谈主永久在回路中。这份指南里,咱们会逐阶段走一遍 Anthropic Applied AI 团队在里面集成 Claude 的最好实践,加快迷惑、让过程跑得更快

现代码不再是瓶颈、构建阶段跑得比传统 SDLC 允许的速率还快时,三件事形成了履行:

→瓶颈移动到了构建阶段的附近两侧。主淌若筹谋、审查/测试和部署,这些关节还在以东谈主的速率运行

→管控技能和履行脱节了。代码是东谈主写的时候,逐行审查是合理的。但当 agent 产出了大部分 diff,逐行审查跟不上了

→治理资本高涨了,因为例外情况如故要走会议和委员会,而这些会每周或每月才开一次

构建不再是治理,治理来自构建两侧那些东谈主速运行的关节

拿安全审查作念个例子。安全团队的东谈主力设立是按东谈主类产出量来的,agent 把代码产出量翻了好几倍之后,要么审查队伍越积越长,要么代码没审就上线了。受监管的组织两种完了都经受不了,安全和合规搜检必须跟上 agent 的速率

要确凿完了 agentic AI 的效用收益并确保安全,传统 SDLC 需要资格和代码实现阶段同等进度的改造

什么是 AI 原生 SDLC

AI 原生 SDLC 是一套再行想象的过程,把旧的管控办法和新的实践方式集中起来。过程从线性形成了轮回,AI 镶嵌到每个节点。AI 原生 SDLC 推动自动化的叮嘱和后续方法的触发,措置的是传统 SDLC 各阶段之间手动、高深的链接问题

AI 原生 SDLC 轮回

重要转换

贯串 AI 原生 SDLC 的中枢看法是提交的产物(committed artifact)。每个阶段完了时往版块限度里写一个产物(intent.md、spec.md、plan.md、代码 diff 特地测试、带审查论断的 PR、事故纪录),下一个阶段从读取这个产物开首

早期阶段的主要产物是 .md 文献,因为居品负责东谈主和 agent 都能读、都能用。从构建阶段往后,产物即是代码和它的纪录了。这条 commit 链本人即是审计链:谁提了什么需求,agent 产出了什么,谁批准了它

东谈主对每一个需要判断力的决策负责。在 agentic SDLC 的宇宙里,东谈主的崇敬力跟着需要审查的产物一齐移动

02 各阶段 Play

Play 是这份手册的中枢,按六个非线性阶段分组(筹谋、想象、构建、测试、部署、运维),遮掩完竣生命周期。每个 play 包含:变化了什么、如何开首、具体实施方法、治理考量、如何揣摸效用

这些方法是模块化的,组织不错根据自身需要优先改造不同阶段。一个阶段在提交产物时完了,此次提交同期启动下一个阶段。一个通过审核的 intent.md 触发需乞降想象关节,一个通过审核的 spec.md 触发 plan mode,一个合并的 PR 触发活水线,线上的监控目的破裂限度带时写出下一个 intent.md,轮回不息

一开首你手动触发每一步,最终景况是每个通过审核的产物自动触发下一个门禁。东谈主的崇敬力集聚在门禁上,审查的是 agent 鲜艳出来的内容,无谓重新开首每个阶段

Play 依赖图:箭头给出经受规矩,从任何莫得箭头指入的 play 开首

03 用 intent.md 拿获意图

intent.md 是软件迷惑过程的最先,不错从不同进口进来。一个东谈主有了思法,一个工单被提交,大约一个告警触发了事故

当一个东谈主有了思法,他和 Claude 一齐首脑风暴,产出一份 Markdown 情势的 proto-spec。传统 SDLC 里,这个东谈主接下来得劝服居品团队的东谈主帮他写或替他写。Claude 生成的 proto-spec 是东谈主类可读的、版块限度的,下一个阶段不错径直奢靡

这是一次性的搭建责任,由平台或工程团队完成。仓库建好之后,莫得 git 教学的东谈主不需要径直用 git。一个联结到 GitHub 的 connector 不错让 Claude 在 claude.ai 或 Cowork 里代替他们提交 Markdown 文献

具体若何作念

第一步,发起东谈主用我方的话向 Claude 形容问题。不需要认真说话

第二步,反复头脑风暴直到思法具体化。Claude 会问分析师该问的问题:鸿沟、用户、治理、若何算告成

第三步,让 Claude 按组织模板把完了写成 intent.md。模板不错编码为一个 skill

第四步,发起东谈主修正 Claude 相识错的所在

第五步,把 intent.md 提交到分享仓库。作家和期间戳加入纪录

一个 intent.md 长这么:

intent.md 示例

# Intent: claims status self-service Author: J. Ortiz (claims operations). Status: draft.

## Problem Customers phone the contact center to ask where their claim is. Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome Customers see claim status, next step and expected date in the portal.

## Affected users and systems Claims handlers, portal team, claims-core API.

## Constraints No new PII in the portal session. Existing authentication only.

## Open questions Do third-party loss adjusters need access too?

治理考量

笔据即是提交的 intent.md,列有作家、期间戳和完竣纠正历史,纪录在 intent 仓库的 git 历史里。居品负责东谈主审批,经受或拒却的决定纪录为合并或关闭审查

04 需求与想象

居品负责东谈主批准后,Claude 拿着通过审核的 intent.md 生成需乞降想象规格诠释。这个过程受组织的 skills 指引,涵盖品牌、安全、合规和 UX

居品负责东谈主审查这份规格诠释,但不写它。这个过程的办法是产出一份工程团队不错据此筹谋的 spec,同期鲜艳出需要关注的所在

前端责任是最直不雅的例子。intent.md 通过审核后,居品负责东谈主在 Claude Design 里基于它作念出 mock,反复迭代,然后导出到 Claude Code 来构建

具体若何作念

居品负责东谈主掀开一个加载了组织 skills 的会话,附上 intent.md。Prompt 指向 intent.md,列出治理条目,要求鲜艳关注点。一开首手动跑,然后编码成组织级别的 slash command。再往后,让 intent.md 在 intent 仓库中被经受这个动作成为触发器

团结个居品负责东谈主对照 idea 审查 spec。先处理鲜艳出来的关注点,居品负责东谈主在工程团队看到 spec 之前,和对应的战略负责东谈主一齐措置每一个。终末把 spec.md 和 intent.md 一齐提交

居品负责东谈主决定 spec 和 intent 是否投入构建阶段,波及组织认定的高风险内容时盘问时期负责东谈主。这个决定永久由东谈主来作念

Prompt 长什么样

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

治理考量

组织的 skills 行为治理条目愚弄在 spec 上。不是等几周后在审查里才发现冲突,而是在 spec 编写时就读取并愚弄了现行战略。Spec、产生它的 prompt、以及奏效的 skill 版块,全部纪录在版块限度里

05 构建阶段Claude Code Plan Mode 行为默许最先

工程师在 plan mode 下启动 Claude Code 会话,给 Claude 第二阶段产出的 spec.md,让它发问、筹谋,反复迭代筹谋,直到工程师平静

工程师把 intent.md 和 spec.md 给 Claude,要求一份实施筹谋:列出要改的文献、责任规矩、解释它 work 的测试。质询筹谋:问这个改造可能轻视什么,哪一步风险最大,Claude 为什么没选其他决策。反复迭代,直到一个从没看过这段对话的工程师也能只凭这份筹谋完成改造

把通过审核的筹谋提交为 plan.md。经受筹谋,让 Claude 实施。有一份塌实的筹谋,实施平时一遍就完成了

plan.md 示例

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py, claims-api/tests/test_status.py

## Order of work 1. Add the status endpoint behind existing auth. 2. Panel against the endpoint. 3. Wire into the portal nav.

## Risks The claims-core API rate-limits at 50 rps; the panel must cache.

## Proof test_status.py covers the four claim states; screenshot matches the approved mock.

治理考量:想象审查发生在职何代码生成之前,改办法还仅仅改文档的事。Plan mode 本人就强制实践了这少量,因为工程师经受筹谋之前 Claude 不可剪辑文献

Claude Code Auto Mode

Claude Code 也不错在 auto mode 下运行。工程师审批筹谋,平静之后 Claude 自动逐一愚弄变更,不需要每次剪辑都阐发。跟着后续 play 的护栏闇练(调好的 CLAUDE.md、编码了战略的 skills、禁锢不安全操作的 hooks、Claude 能我方跑的测试套件),auto-accept 成为旧例责任的默许模式

崇敬力的重点从「看着 agent 作念每一次剪辑」转向「在更长的自主会话之后审查产物」

CLAUDE.md

CLAUDE.md 给 Claude 提供一个新东谈主入职第一天需要知谈的东西:代码步调、呐喊、架构、团队最常见的无理。当年存在东谈主脑里和 wiki 上的常识,形成了 agent 每次会话起原都会读的文献,由扫数这个词团队颐养,每犯一次错就迭代一次

在仓库里跑 /init,Claude 从它发现的东西里生成一个运行版块。把它精简到新东谈主第一天需要的内容。一条实用规定:Claude 犯团结个错两次,纠正就进 CLAUDE.md。限度在一页以内

CLAUDE.md 示例

# Payments service

## Commands – Build: make build – Test: make test (unit), make itest (integration, needs docker) – Lint: make lint (runs in CI; fix before pushing)

## Conventions – Java 21, Spring Boot 3. No new Lombok. – Money is always BigDecimal, never double. – Every endpoint needs an integration test in src/itest.

## Architecture – api/ holds REST controllers, core/ holds domain logic,

adapters/ talks to external systems. – Kafka events are defined in schemas/;

never edit generated classes.

## Things Claude gets wrong – Do not bump dependency versions;

the platform team owns them. – The legacy v1/ package is frozen; changes go in v2/.

Skills:机构常识的可实践化

Skills 是组织让机构常识确凿推崇作用的方式。提示是显式的、版块限度的、无为适用的,战略变化时集聚更新。教学法例:需要一致性实践的机构常识写成 skill

找一条今天实践不一致的常识,写成 skill,放在仓库的 .claude/skills/ 目次里让它随代码一齐分发。战略变化时改 skill,工程师不才一次会话自动取得新版块

.claude/skills/secure-api-review/SKILL.md 示例

— name: secure-api-review description: Apply the API security standard. Use whenever

creating or modifying an external-facing endpoint,

reviewing API code, or generating an OpenAPI spec. — # Secure API review

When you create or change an API endpoint: 1. Authentication: every endpoint requires the gateway JWT;

no anonymous routes outside /health. 2. Input validation: validate request bodies against the

OpenAPI schema and reject unknown fields. 3. Audit: every state-changing endpoint emits an audit event

with actor, action, entity and timestamp. 4. Data classification: fields tagged pii in the schema must

never appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

治理考量:Skill 是一种管控技能,然而建议性的。必须无条目实践的战略需要在 skill 背后加一层细目性的东西,比如 hook。Skill 让违章变得罕有,hook 让违章险些不可能

Hooks:构建阶段的护栏

Skill 是建议性管控,hook 是背后的细目性层。Claude 在实施阶段的大部分操作是文献剪辑和 shell 呐喊,是以构建阶段是 hook 触发最通常的所在

构建阶段的 hook 不错作念这些事情:封闭对受保护旅途的剪辑(比如生成的类或冻结的包),在文献剪辑后跑 formatter 和 linter,把凭证挡在 diff 以外

Hook 在每个匹配的操作上运行,是以构建阶段的 hook 要快、鸿沟要限定在改造的文献上。更重的搜检(比如跑完竣测试套件)应该放在 commit 或 PR 阶段

并行会话和子 Agent

一个工程师不错同期推动多条责任流

并行会话是另一个完竣的 Claude Code 实例,在各自的 git worktree 里处理寂寥的任务。每个寂寥会话互不知谈对方的存在,工程师是它们唯独的分享点

子 agent(subagent)运行在单个会话里面,有我方的险阻文窗口和器具权限,稳当在多个任务中重叠出现的责任,比如考证愚弄是否按预期运行

用第三阶段 plan mode play 的筹谋,把责任拆成改造不同文献的任务。每个并行任务用我方的 worktree,比如一个末端里 claude –worktree feature-auth,另一个末端里 claude –worktree fix-rate-limit。两到三个会话是合理的最先

把重叠的责任形成子 agent,界说在 .claude/agents/ 的 Markdown 文献里:

.claude/agents/verifier.md

— name: verifier description: Runs the app and checks the change works

before the session reports done tools: Bash, Read — Start the app with make run. Exercise the changed behavior and the two nearest neighboring flows. Report what you ran, what you saw, and any behavior that does not match plan.md. Do not fix anything; report only.

给 Claude 一个反馈回路

永久给 Claude 一种考证我方责任的方式,岂论是测试、构建如故截图 diff。会话我方搜检我方的责任,我方修正我方的无理,然后工程师才看到

如果搜检责任当今需要一连串呐喊和一些环境常识,把它包装成一个 target,比如 make test 或 npm test,失败时复返非零退出码。在 CLAUDE.md 的 Commands 部分列出每个呐喊和健康输出的示例

修 bug 时先写失败的测试。让 Claude 把 bug 复现为测试,跑一遍,阐发它因为预期的原因失败。提交阿谁测试。然后才让 Claude 在不剪辑测试的前提下迷惑它。一个迷惑前就存在、agent 不可改写的测试,即是 bug 已摒除的笔据

回路本人也需要保护。修代码的 agent 不可同期数落对那段代码的搜检。一个在迷惑任务期间封闭剪辑测试文献的 hook 不错作念到这少量

CLAUDE.md 考证块

## Verifying your work

– Build: make build (must finish with “Build succeeded”) – Test: make test (all green; never skip or delete

a failing test) – Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output. If a test fails, fix the code, not the test.

06 测试阶段CI 中的握续 Eval

Eval 是 AI 原生宇宙里的 stage-gate QA。具体来说即是一个测试套件,在 agent 的设立变化时运行。换了新模子或改了 prompt,eval 套件会告诉你 agent 是否还能保握相同的责任圭臬

平台工程师从近期责任中收罗 20 到 50 个果然任务特地预期/通过的完了。把每个任务写成 eval:prompt 加上界说「可经受」的搜检项(测试通过、lint 干净、步履不变、战略被治服)。每个出产事故都形成一个 eval,行为回想测试永远留在套件里

.github/workflows/agent-evals.yml

name: Agent evals on:

pull_request:

paths: [‘CLAUDE.md’, ‘.claude/**’]

schedule:

– cron: ‘0 2 * * *’ jobs:

evals:

runs-on: ubuntu-latest

steps:

– uses: actions/checkout@v4

– run: npm install -g @anthropic-ai/claude-code

– name: Run eval suite

env:

ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

run: |

for eval in evals/*.json; do

claude -p “$(jq -r ‘.prompt’ $eval)”

–allowedTools “Read,Edit,Bash(make test)”

–output-format json > result.json

./evals/check.sh “$eval” result.json

done

AI 参与 PR 审查

Claude 既作念审查者,也作念被审查者。它按组织战略审查传入的 PR,同期处理我方 PR 上收到的审查意见。工程师不错把 PR 审查的崇敬力集聚在步履上:判断意图和风险

时期负责东谈主把审查战略写成仓库根目次的 REVIEW.md,分红组织柔和的几个维度:bug 和逻辑无理、安全和错误、是否合适 spec。REVIEW.md 还界说什么算 Important、什么算 Nit、以及什么不错跳过

审查者或作家在审查评述上 @claude 时,Claude 处理评述并推送迷惑。关于 Claude 我方开的 PR,不错更进一步,让 Claude 撑握 PR 直到合并:扫描未措置的审查评述和失败的 check,处理它们并推送迷惑,日中则昃,直到 PR 是绿的、只等代码扫数者批准

审查论断反馈到 CLAUDE.md。团结个无理第二次被审查鲜艳时,纠正就在那次审查中写入 CLAUDE.md。因为审查会读 CLAUDE.md,从下一个 PR 开首这个无理就会被提前拿获

REVIEW.md 示例

# Review instructions

## Passes Run three passes and tag each finding with its pass: – Bugs: logic errors, broken edge cases, subtle regressions – Security: injection risks, authentication gaps, PII in logs – Compliance: the change matches spec.md, plan.md

and our design principles

## What Important means here Reserve Important for findings that would break behavior, leak data or breach a policy. Style and naming are nits.

## Cap the nits Report at most five nits per review; summarize the rest as a count.

## Do not report Generated files under src/gen/ and anything CI already enforces.

治理考量:职责别离得到保握。写代码的 agent 莫得路线批准我方的代码。审查战略对扫数 PR 奏效。批准来自东谈主(通过分支保护),依据是审查论断

07 部署阶段Hooks 行为审批门禁

构建阶段的 hook 是护栏,允许或封闭操作,不需要东谈主介入。但 hook 也不错暂停操作直到特定的东谈主批准,这恰是发布门禁需要的

工程提示层与变更管理和合规团队一齐,列出必须保留的东谈主工审批门禁。平台工程师把每个门禁抒发为 hook。团队 hook 放在 git 里的 .claude/settings.json,不可协商的 hook 放在平台管理员领有的 managed settings 里,个东谈主工程师无法关闭

.claude/settings.json

{

“hooks”: {

“PreToolUse”: [

{

“matcher”: “Bash”,

“hooks”: [

{ “type”: “command”,

“command”: “${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh” }

]

}

]

} }

.claude/hooks/production-gate.sh

#!/bin/bash # Production deploys require a named release authorization cmd=$(jq -r ‘.tool_input.command’ < /dev/stdin) if [[ “$cmd” == *”deploy”* && “$cmd” == *”production”* ]]; then

if [ -z “$RELEASE_APPROVAL” ]; then

echo “Production deploys need a release authorization.” >&2

exit 2

fi fi exit 0

治理考量:Hook 即是审批门禁。门禁条目每次实践、对每个东谈主实践。允许和封闭的决定带期间戳纪录

CI/CD 集成与部署

在 CI/CD(Continuous Integration / Continuous Delivery,握续集成与握续委用)活水线里非交互式地运行 Claude Code,沙箱化实践让持久间运行的 agent 安全运行,通过 MCP(Model Context Protocol,模子险阻文左券)集成知晓部署智商,在 agent 确凿需要之前先演练回滚旅途

平台工程师从只读的判断方法开首。在活水线 job 里用 claude -p 来分类失败的构建、总结 flaky 测试、或草拟 changelog。在现存门禁背面加写入方法。Agent 写的任何东西都通过分支保护行为 PR 到达,agent 莫得径直推送到 main 的旅途

通过 MCP 知晓部署智商。部署、景况查询和回滚形成器具,按环境限定鸿沟。按环境分级自主权:迷惑环境里 agent 摆脱部署,出产环境里 agent 准备发布、发布司理授权,预发布环境介于两者之间

回滚应该是活水线里演练最多的旅途:一条呐喊,agent 能跑,在预发布环境里依期演练

活水线方法示例

– name: Triage failed build

if: failure

run: >

claude -p “Read the build log at out/build.log.

Identify the most likely cause, say whether the failure

looks flaky or real, and write a three-line summary

for the PR thread.” >> triage.md

治理原则:agent 不错作念到出产门禁为止,不可进步它。分支保护把 agent 写的任何东西形成 PR。出产部署 hook 在发布司理授权前封闭发布。每次非交互式运行都以 agent 我方的身份实践,活水线日记把 agent 作念的事和触发它的工程师作念的事分开

08 运维与闭环

到咫尺为止,每个阶段都需要东谈主来启动运行方法。这个阶段的重点是 Claude 的自主运行来闭合扫数这个词轮回

比如一个握续运行的监控 agent 不错在一个 bug 工单被提倡时创建 intent.md,然后流经需求、筹谋、构建、测试和审查阶段。第六阶段无东谈主值守地运行,阶段之间有寂寥的信心门禁来决定上一阶段的产出是不息流转如故升级给东谈主处理

闭合轮回

一个细目性剧本监控出产环境,在限度带被破裂时调用 Claude

行状负责东谈主或平台工程师选一个有平安滚动基线的目的,比如 CI 测试失败率、部署后 5xx 率、或 PR 周期期间。写检测剧本:平时是滚动窗口上的均值和圭臬差,加规定(Western Electric 或访佛方法)。检测层所有细目性,不波及模子

在版块限度的设立文献里界说反映分级。1σ 只记日记,2σ 调用 Claude 只读会诊,3σ Claude 不错活动(但只可通过开 PR 投入审查门禁或触发事先批准的 runbook)

bands.yaml 示例(监控 CI 测试失败率)

metric: ci_test_failure_rate baseline: rolling_30d rules: western_electric tiers:

1sigma: { action: log }

2sigma: { action: diagnose,

tools: “Read,Grep,Bash(gh run view *)” }

3sigma: { action: propose,

routes: [pull_request, runbook:rollback-deploy] }

Agent 按第一阶段情势把会诊写成 intent.md:特地特地笔据、预期完了、受影响的系统、待解答的问题。从这里开首,发现的问题和其他任何东西一样走活水线

几个本体场景:

→ CI 测试失败率破裂 3σ 时,agent 防碍 flaky 测试或开一个 revert PR,审查门禁作念决定

→ 部署后 5xx 率破裂 3σ 且期间窗口内有部署时,agent 触发现存的回滚活水线

→ PR 周期期间触发漂移规定时,agent 为工程提示层写一份阐明。这诠释这套机制对过程目的和出产目的都管用

Claude Tag:Claude 随叫随到

事故也不错通过 Slack 或 Teams 这么的责任通信器具到达。Claude Tag(咫尺在 Slack 里公开 beta)让 Claude 以我方的身份成为频谈的成员,每个新事故都能拿到第一反映

对话和机构常识留在频谈里,任何团队成员都能测试假说、探索新决策、及时捕快,频谈历史加多了可审计性。通过 MCP 探问,Claude 考证目的回到基线并在帖子里阐发,把过后复盘写到版块限度的教学文献里

事故不是 Claude Tag 接办的唯独责任。小的、范围明晰的迷惑行为 PR 投入审查门禁,更大的责任被写成 intent.md 投入第一阶段,轮回开首自我喂养

频谈即是审计链:央求、会诊、东谈主的授权和迷惑,全部留在事故被处理的所在

收尾

模子和框架越来越闇练了。组织当今不错改造的不仅仅写代码的方式,而是扫数这个词软件迷惑生命周期

这种改造把东谈主的判断力放在过程的中心位置,同期洽商了大型企业组织的治理和合规要求

这份指南整合了 Anthropic Applied AI 团队每天为客户实践的果然最好实践。但愿对你有效

本文由东谈主东谈主都是居品司理作家【赛博禅心】,微信公众号:【赛博禅心】,原创/授权 发布于东谈主东谈主都是居品司理,未经许可,防碍转载。

题图来自官网截图开云体育