Part 1去魅论——什么是 Harness Engineering这是我参与过的最有效的工程治理体系名字听着很唬人。但如果我直言Harness Engineering 就是把大厂沉淀了几十年的角色分工、流程规范、责任边界虚拟化重构后锁死在三个 Markdown 文件里。没有魔法。在大公司里架构师写设计文档开发按图纸拧螺丝QA 挑刺。职责分离是防止自我包庇的唯一方法。当 AI 开始成为主力生产单元时我们面临一个问题如何让 AI 遵守同样的职能分工而不是让它自己当架构师、又当开发、还当验收答案就在你手里握着的这三个文件。对比一下两种思路手艺人思维写个 Prompt让 AI 把代码敲出来吹捧一番很聪明啊然后上线。代码坏了微调 Prompt。需求偏了再微调。整个系统的质量完全取决于那一刻 Prompt 的质量没有规律可言。Solution Architect 思维定义三权分立——谁规划谁实现谁验收定义每个角色的职责边界锁死在文件里让 AI和人类开发者无法越权。程序员的价值从此转变不再是敲代码的手感而是定义系统权责边界的能力。让我展开讲。Part 2指挥权——.github/copilot-instructions.md这是第一份文件叫指挥权因为它定义了谁有权指挥谁。Agent 角色与职责| Agent | Role | Responsibility ||-------|------|----------------|| **plan_agent** | 架构师 / 高级数据分析师 | 执行 EDA 理解数据制定数据驱动的任务路线图 || **code_agent** | 资深开发 | 依据 roadmap 实现功能编写单元测试 || **analyzer_agent** | 质检官 (QA) | 运行集成测试验证业务验收标准发布 issue |为什么必须三个角色这不是简单的分工而是Agile 开发的核心诉求开发与验收必须物理隔离。plan_agent架构师不能写代码只能出图纸。它的任务是通过 EDA探索性数据分析去理解真实的数据然后基于数据现实制定任务路线图roadmap。code_agent开发不能定义需求只能按图纸拧螺丝。它的责任是贴着 roadmap 实现功能并确保 100% 的单元测试覆盖。analyzer_agentQA既不规划也不开发只负责挑刺。它要运行集成测试连接真实的数据仓库验证业务验收标准如果有问题就记录在 Issue Tracker 里。核心悟点如果这三个角色混在一起呢AI 会在规划的时候自己想象数据长什么样没见过真数据然后开发出来的代码完美地处理了这个幻想数据最后自己跑一遍单测当然通过了因为 mock 数据就是按照幻想来的然后自信地说一切就绪这就是自我包庇。大多数90%完成的项目死在这里。六阶段工作流让我贴出完整的工作流定义### X0.1 PHASE 0 — Create Agents (Initial Setup)Goal: Create 3 GitHub Copilot agent manifest filesOwner: Manual Setup### X0.2 PHASE 1 — Local Dev SetupGoal: Verify access to all required data sourcesOwner: plan_agent- [ ] Verify data warehouse connection succeeds- [ ] Verify business strategy documentation is readable- [ ] Verify all dependencies installed### X0.3 PHASE 2 — Exploratory Data AnalysisGoal: Understand actual data and strategy BEFORE planningOwner: plan_agentReference: A2 Exploratory Data Analysis- Inspect data warehouse table structure (columns, types, nulls)- Analyze business strategy documents for segmentation rules- Map business rules to actual data columns and aggregations- Document findings in artifacts/eda_report.md### X0.4 PHASE 3 — Data-Driven PlanningGoal: Build PROJECT-SPECIFIC roadmap based on EDA findingsOwner: plan_agentReference: A2.5, A2.6, X1- Review EDA report findings- Align business requirements with data reality- Create artifacts/execution_roadmap.md with tasks, dependencies, and sequence- Assign priority and owner for each task### X0.5 PHASE 4 — Implementation and TestingGoal: Build working software following architecture and test all changesOwner: code_agentReference: B1, B2, B3.4, B4, B51. Read artifacts/execution_roadmap.md (data-driven version)2. Reference EDA report for actual data structure3. For each task (in priority order): - Implement feature following B1 Architecture Principles - Write unit tests using mocks/stubs (B4.1) — target 100% coverage - Run full test suite locally; all tests must pass - Include test results in artifacts/CHANGELOG.md4. Update task status in artifacts/execution_roadmap.md → COMPLETED5. Add feature entry to artifacts/CHANGELOG.md### X0.6 PHASE 5 — Validation and Quality GatesGoal: Verify all work meets quality standards and is ready for productionOwner: analyzer_agentReference: B4, B5, X3, Quality Gates below1. Review code_agent output against quality gates2. If issues found, append entries to artifacts/issues.md3. **Run the Tier 2 integration tests against real data warehouse** (see B4.2): pytest tests/test_integration.py -v -m integration All integration tests must pass. If data warehouse is unreachable, log a BLOCKER.4. **Run the full pipeline against real data warehouse data** and save the output report: python -m src.main --limit 5000 --output artifacts/report.json --log-level INFO - Verify artifacts/report.json is valid JSON and passes schema validation - Record timing, record count, and segment distribution in artifacts/CHANGELOG.md - This is MANDATORY — a CSV-only smoke test does NOT satisfy this gate5. Validate task completion; update artifacts/execution_roadmap.md → VALIDATED6. Add validation entry to artifacts/CHANGELOG.md为什么这个顺序不能乱大多数团队的做法是需求来了 → 直接开发 → 匆匆上线。这套流程强制你必须先跑 EDAPhase 2 3然后才能编码Phase 4。为什么因为没见过真数据的规划就是空想。在一个零售数据分析项目中我们发现产品说“我们需要按采购频次和商品品类分段”EDA 发现采购频次的数据大量缺失品类信息散布在多个不同字段里规划被迫调整改用订单金额和最近采购日期作为分段依据如果没有 EDA代码会死劲儿去处理一个不存在的列。Part 3目标权——business_requirement.md这是第二份文件叫目标权因为它定义了什么才是成功。AI 有个通病**容易在复杂的对话中偏离目标最后产出一堆精美的废话**——代码很漂亮测试覆盖也不错但完全解决的不是业务问题。这份文件是给 AI 设置的终点线。它必须对照验收标准逐条打勾。验收标准Acceptance Criteria这是一个零售数据分析项目的虚构例子脱敏处理## Acceptance Criteria (验收标准)- [ ] 报告必须聚合客户层面的指标交易频次、商品品类偏好。- [ ] 必须从业务策略文档中提取分级规则。- [ ] 最终报告必须为格式合法的 artifacts/report.json。- [ ] **全链路必须在真实的数据仓库环境下跑通并产出数据。**每一条都有具体的检查点“聚合客户层面的指标”← 这意味着什么不是汇总产品不是汇总地区必须是客户粒度每个客户一条记录。“商品品类偏好”← 不能说推断或估算必须是真实存在的字段值。“从业务策略文档中提取”← 不能靠 AI 胡编必须真的从那份文档里找到规则白纸黑字。“真实的数据仓库环境下跑通”← 单测通过不算必须连接生产数据库用真实数据跑一遍。质量门Quality Gates这是验收的严格检查清单。在 code_agent → analyzer_agent 的边界必须全部打勾### Before code_agent → analyzer_agent1. ✅ All code written and committed2. ✅ All unit tests passing locally3. ✅ Type hints on 100% of functions4. ✅ artifacts/CHANGELOG.md entry created5. ✅ Acceptance criteria checklist completed看起来很简单但All unit tests passing locally是个陷阱。Local 通过 ≠ 真实环境通过。所以在 analyzer_agent 这一侧还有更狠的门### Before analyzer_agent → APPROVAL1. ✅ Code review passed2. ✅ Unit tests: 100% coverage, all passing3. ✅ Type checking clean (mypy)4. ✅ Architecture compliance verified5. ✅ Documentation complete6. ✅ **Tier 2 integration tests run against real data warehouse — all passing**7. ✅ **Full pipeline executed against real data warehouse — artifacts/report.json generated and schema-valid**8. ✅ artifacts/CHANGELOG.md validation entry added9. ✅ artifacts/execution_roadmap.md marked VALIDATED第 6 和第 7 项是真刀真枪集成测试必须跑全链路必须在真库上走一遍最后的报告文件必须过 Schema 校验。这就是验收的铁血标准。很多项目在第 6 项就栽了——因为没人真的连过数据仓库。Part 4约束权文章的重头——technical_restrictions.md这是整套系统最硬核的部分。如果说前两份文件是治理框架这一份就是工程底线。它定义了什么样的代码、什么样的流程、什么样的输出才能在这套系统里活下来。4.1 强制 EDA没见过真数据的代码全是幻觉我想强调一个观点EDA探索性数据分析不是数据分析师的工作它是整个系统的基础真实。如果你跳过它后面的所有决策都建立在沙滩上。EDA 的五步工作流Step 1数据探索### A2.1 Step 1 — Data ExplorationAnalyze the data warehouse table and document:- Column names and data types- Data distributions (mean, median, quantiles for numeric columns)- Null/missing values per column- Unique values for categorical fields- Date ranges for temporal>TABLE: retail_analytics.customer_transactions_v1Column Analysis:- customer_id: string, 245,680 distinct values, 0 nulls (✓ 主键可用)- transaction_date: timestamp, range 2023-01-01 ~ 2026-04-12, 1.2% nulls (△ 需要处理)- category_code: string, 18 distinct values, 8.5% nulls (△ 需要策略处理)- transaction_amount: decimal, mean128.50, median89.20, 0.3% nulls, outliers 50k (△ 需要 cap)- product_category: string, 12 distinct values: electronics, home, fashion, food, etc.就这几行代码你发现了customer_id是好的主键transaction_date大部分靠谱但要处理 nullcategory_code有缺失需要降级或补全策略transaction_amount需要做异常值处理product_category相对完整和可靠没有这个发现后面的分段逻辑会有多少坑Step 2策略文档深潜### A2.2 Step 2 — Strategy Material Deep Dive1. Extract all text from business strategy documents2. Identify: segmentation criteria, thresholds, customer categories, usage metrics, business rules3. Map each identified rule to the actual data warehouse columns**Output**: artifacts/eda_strategy_analysis.md- Segment definitions with exact criteria and column mappings- Usage metrics and how to derive them from available>### A2.3 Step 3 — Gap AnalysisCompare business requirements with data reality:- What the strategy requires vs. what the data provides- Missing fields, required workarounds, or blockers- Impact of data quality issues on segment assignments- Constraints (date range, granularity, performance)EDA 发现的差距可能是产品想要年交易品类多样性但数据里category_code有 8.5% null → 决策null 当作 Unknown计数时归为一类产品想要客户忠诚度交易频次但transaction_date有 1.2% null → 决策用 MAX(transaction_date) - MIN(transaction_date) 来计算客户活跃周期忠诚度 交易数 / 活跃周期产品想要季节性分析但历史数据只有 15 个月 → 决策季节性不可靠改用近 3 个月趋势Step 4 5EDA 报告 数据驱动的规划### A2.4 Step 4 — EDA ReportConsolidate into artifacts/eda_report.md with:- Executive summary (data sources, key findings, blockers)- Data overview (from Step 1)- Strategy overview (from Step 2)- Business rules mapped to data columns with explicit thresholds- Data quality constraints (from Step 3)- Specific aggregation logic and cleanup steps required- **Recommended task list and priority order for artifacts/execution_roadmap.md**这就是 plan_agent 最重要的产出。不是图纸而是基于现实的图纸。code_agent 拿到这份报告会知道哪些列能用哪些列是垃圾数据的真实分布不是猜的要处理哪些边界情况分段逻辑的具体实现方式成功标准是什么### A2.6 Success Criteria**ALL of the following must be true before handing off to code_agent**:- ✅ Table fully explored; statistics documented- ✅ All columns analyzed (type, nulls, distributions)- ✅ Strategy documents fully extracted and mapped to data columns- ✅ Segment definitions identified with explicit numeric thresholds- ✅ Business rules mapped to actual data warehouse columns- ✅ Gaps between expectations and data reality documented- ✅ artifacts/eda_report.md completed and project-specific- ✅ artifacts/execution_roadmap.md created from EDA findings **If any gap exists or understanding is incomplete**: STOP — do more EDA before planning.如果你跳过 EDA 直接开发等价于在没有勘探的情况下就开始建楼。倒塌是 100% 确定的事。4.2 分级测试单测只是开始很多工程师的理解是写单测 → 单测通过 → 完工。但在这套系统里单测通过只是入场券不是毕业证。Tier 1单元测试离线逻辑### B4.1 Tier 1 — Unit Tests (离线逻辑)**目标**100% 覆盖业务计算工具如分类逻辑函数。**约束**严禁连接生产数据库必须使用 Mock 数据。单元测试用 Mock 数据完全离线速度极快。100% 覆盖的意思是每一条 if / else 分支都要被测试到。这是 code_agent 必须保证的。Tier 2集成测试在线验证### B4.2 Tier 2 — Integration Tests (在线验证)**目标**验证数据仓库权限、Schema 兼容性和端到端全流程。**约束**这是 Phase 5 验收的唯一准入硬指标。集成测试是什么意思连接真实的数据仓库用真实的数据跑一遍整个流水线。import pytestfrom data_warehouse import DataWarehouseSessionfrom src.main import main as run_pipelinepytest.mark.integrationdef test_full_pipeline_on_warehouse(): PHASE 5 gate: Must run against REAL data warehouse warehouse DataWarehouseSession.builder.profile(PROD).getOrCreate() # Step 1: Can we connect? try: table_df warehouse.read.table( retail_analytics.customer_transactions_v1 ) row_count table_df.count() assert row_count 0, Table is empty! except Exception as e: pytest.skip(fData warehouse connection failed: {e}) # Step 2: Can we load a sample and compute segments? sample_df table_df.limit(1000).toPandas() assert len(sample_df) 1000, Sample load failed assertcustomer_idin sample_df.columns, Missing customer_id column asserttransaction_amountin sample_df.columns, Missing transaction_amount column # Step 3: Run the full pipeline (this is expensive) result_json run_pipeline( limit5000, output_pathartifacts/test_report.json ) # Step 4: Validate output schema assert result_json[status] success assertsegmentsin result_json assert len(result_json[segments]) 0 # Step 5: Check segment distribution makes sense segments_df pd.DataFrame(result_json[segments]) vip_count len(segments_df[segments_df[segment] VIP]) basic_count len(segments_df[segments_df[segment] Basic]) # VIP should be smallest, Basic should be largest (usually) assert vip_count basic_count, Segment distribution looks wrong # Step 6: Verify no data quality issues assert segments_df.isnull().sum().sum() 0, Output has NULLs! assert segments_df[segment].isin([VIP, Regular, Basic]).all(), \ Unexpected segment values这个测试贼难通过。因为它接触真实数据真实的数据仓库连接真实的网络波动。但这正是重点单测通过 ≠ 系统可用。在类似的零售分析项目中我们遇到过这样的情况单测全绿 ✓代码审查通过 ✓本地跑通 ✓集成测试一运行…KeyError: product_category为什么因为预发环境的数据仓库表 schema 和开发环境不一样。字段名叫product_category_v2不是product_category。没有 Tier 2这个 bug 上线就是线上故障。4.3 异步纠偏Bug Tracker 作为 Agent 通讯协议分工的最后一环是怎么反馈问题。在传统团队里QA 找到 bug开发说这不是 bugQA 说就是 bug在会议室吵半天。在这套系统里Agent 之间不在对话框里吵架而是通过结构化的 Issue Tracker 协作。Issue 的标准格式## [VAL-YYYYMMDD-NN] one-line summary| Field | Value ||-------|-------|| **id** | VAL-YYYYMMDD-NN || **severity** | BLOCKER / HIGH / MEDIUM / LOW || **status** | OPEN → IN PROGRESS → RESOLVED → CLOSED || **added_by** | analyzer_agent || **timestamp** | YYYY-MM-DD HH:MM || **files** | src/tools/segment.py lines 45–52 || **evidence** | failing test name / error message / log || **suggested_fix** | short guidance for developer || **resolved_by** | code_agent || **validated_by** | analyzer_agent || **closed_at** | YYYY-MM-DD HH:MM |Status 流转OPEN(analyzer_agent 创建) →IN PROGRESS(code_agent 开始修) →RESOLVED(code_agent 修完重新跑测试) →CLOSED(analyzer_agent 验收)真实案例缺失值处理场景analyzer_agent 在 Phase 5 运行集成测试发现问题。## [VAL-20260410-07] Segment calculation fails when category is NULL| Field | Value ||-------|-------|| **id** | VAL-20260410-07 || **severity** | BLOCKER || **status** | OPEN || **added_by** | analyzer_agent || **timestamp** | 2026-04-10 14:23 || **files** | src/tools/segment.py lines 45–52 || **evidence** | Test failure: test_full_pipeline_on_warehouse AssertionError at line 67: NaNs in output || **suggested_fix** | In segment_customer(), handle null category case. Treat as Unknown category. Update category_diversity check to skip nulls. || **resolved_by** | code_agent || **validated_by** | analyzer_agent || **closed_at** | 2026-04-10 16:45 |code_agent 看到这个 Issue 后的行动打开src/tools/segment.py找到第 45–52 行看当前逻辑plaintextcategories len(customer_data[‘category_code’].unique())发现问题如果category_code里有 NaNunique()会把 NaN 算进去导致长度不对修复plaintextcategories len(customer_data[‘category_code’].dropna().unique())重新跑所有单元测试都通过更新 Issue 的 status: RESOLVED让 analyzer_agent 重新跑集成测试analyzer_agent 的验证重新跑test_full_pipeline_on_warehouse确认✅ 集成测试通过✅ 输出的artifacts/report.json没有 NaN✅ 段分布看起来合理然后关闭 Issuestatus → CLOSED记录 closed_at 时间戳。这个过程的关键点Issue 是结构化的不是聊天记录问题有明确的证据哪个测试失败了修复有具体的指导不是别这样而是试试这样修复完了要重新验收不是 code_agent 自己说我改好了Part 5整体协调——六阶段工作流的完整图景我们已经分别讲了指挥权、目标权、约束权。现在把这些串起来看看完整的工作流是什么样的。工作流图PHASE 0: Create Agents (Manual Setup) ↓PHASE 1: Local Dev Setup (plan_agent验证数据源) ↓PHASE 2: Exploratory Data Analysis (plan_agent跑EDA) ↓PHASE 3: Data-Driven Planning (plan_agent出roadmap) ↓PHASE 4: Implementation Testing (code_agent开发单测) ↓PHASE 5: Validation Quality Gates (analyzer_agent集成测试验收) ↓APPROVED (所有质量门通过可以上线)每个 Phase 的守卫PHASE 2→3 的守卫EDA 必须完整If any gap exists or understanding is incomplete: STOP — do more EDA before planning.你不能跳过 EDA。必须真的理解了数据才能规划。PHASE 3→4 的守卫Roadmap 必须数据驱动### A2.6 Success Criteria (before code_agent can start)- ✅ Table fully explored; statistics documented- ✅ All columns analyzed (type, nulls, distributions)- ✅ Segment definitions identified with explicit numeric thresholds- ✅ Business rules mapped to actual data warehouse columns- ✅ artifacts/execution_roadmap.md created from EDA findingscode_agent 不能说EDA 报告里没提这事而自作聪明。必须严格按 roadmap 来。PHASE 4→5 的守卫Quality Gates### Before code_agent → analyzer_agent1. ✅ All code written and committed2. ✅ All unit tests passing locally3. ✅ Type hints on 100% of functions4. ✅ artifacts/CHANGELOG.md entry created5. ✅ Acceptance criteria checklist completed这是 code_agent 对自己的承诺。如果有一项不满足就不能交给 analyzer_agent。PHASE 5 的守卫Integration 必须真实### Before analyzer_agent → APPROVAL6. ✅ **Tier 2 integration tests run against real data warehouse — all passing**7. ✅ **Full pipeline executed against real data warehouse** — artifacts/report.json generated and schema-valid8. ✅ artifacts/CHANGELOG.md validation entry added9. ✅ artifacts/execution_roadmap.md marked VALIDATED这不是 code_agent 的任务。analyzer_agent 必须亲自跑一遍看到 green 的 test看到生成的 JSON 文件。文件的流转整个流程通过三个关键文件协调文件创建者读者内容artifacts/eda_report.mdplan_agentcode_agent, analyzer_agent数据现状、分段规则、边界情况artifacts/execution_roadmap.mdplan_agentcode_agent, analyzer_agent任务列表、依赖关系、状态追踪artifacts/CHANGELOG.mdcode_agent analyzer_agent所有人实现记录、测试结果、验收记录artifacts/issues.mdanalyzer_agentcode_agent问题记录、修复跟踪artifacts/report.jsoncode_agent (Phase 4)analyzer_agent (Phase 5)最终输出必须是真实数据仓库跑出来的这些文件就像神经网络的突触让三个 Agent 能在没有实时对话的情况下完美协调。Part 6Solution Architect 的溢价到这里我要问一个问题为什么要费这么大功夫直接让 AI 一个人搞不行吗答案是短期可以长期不行。程序员的三个进化阶段L0手艺人— 只会敲代码出题“写个客户分层系统”做法“行我给你敲”质量取决于那一刻的 Prompt 质量波动极大可维护性依赖个人可复用性几乎为零L1工程师— 知道怎么写好代码出题“写个客户分层系统”做法“我用 TDD、设计模式、100% 单测覆盖”质量稳定代码漂亮可维护性代码可维护但需求理解可能有偏差可复用性还是依赖这个人的代码库L2Solution Architect— 能定义系统的权责边界就是你现在学的出题“用这三个文件 六阶段流程解决这个问题”做法“我不管你是人还是 AI只要你遵守这套框架”质量框架本身就保证质量因为有三权分立、质量门、真实数据测试可维护性极强因为所有决策都记录在文件里可复用性这套框架可以克隆到任何项目三个文件的威力让我再强调一遍这三个文件加在一起是什么.github/copilot-instructions.md← 权责分工谁规划plan_agent谁开发code_agent谁验收analyzer_agent每个人的输入输出明确到文件级别business_requirement.md← 目标锚定什么是成功逐条列出验收标准怎么证明成功质量门 checklist没有达到就是没完成technical_restrictions.md← 工程底线必须跑 EDA禁止盲目编码必须分级测试单测 集成测试必须真实数据验证数据仓库集成测试必须记录所有问题结构化 Issue Tracker把这三个文件丢给任何一个老旧的代码库它立刻就能长出一套为其量身定制的、具备大厂规范的开发流水线。程序员的新溢价在 AI 时代你的价值不再体现在敲代码的手感上而是能否定义清晰的权责边界← 这是架构师的核心技能能否设计有效的质量门← 这是工程管理的核心技能能否写出具体可执行的规范文件← 这是沟通的核心技能你手里握着这三个文件就握着一台自进化、可克隆的生产力机器。同一套框架可以套用到推荐系统不同的 AI 模型尝试风控模型不同的特征工程方案数据平台不同的表结构和 ETL 流程搜索引擎不同的排序算法框架不变具体实现的细节会变。但那套先 EDA、再规划、再开发、再验收的逻辑永远有效。总结没代码不 BB这就是 Harness Engineering 的全貌。如果你要我用一句话总结我会说这套系统的核心不是某个技术决策而是一种治理哲学——通过明确的分工、明确的目标、明确的约束把 AI和人类开发者变成工业级的生产单元而不是聊天机器人。没有魔法只有三个 Markdown 文件六个清晰的阶段若干个质量门结构化的 Issue Tracker一个必须用真实数据验证的铁血要求做到这些你就不再是代码手艺人而是解决方案架构师。你的价值从此开始溢价。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Harness Engineering：从代码手艺人到解决方案架构师
发布时间：2026/6/4 22:30:49
Part 1去魅论——什么是 Harness Engineering这是我参与过的最有效的工程治理体系名字听着很唬人。但如果我直言Harness Engineering 就是把大厂沉淀了几十年的角色分工、流程规范、责任边界虚拟化重构后锁死在三个 Markdown 文件里。没有魔法。在大公司里架构师写设计文档开发按图纸拧螺丝QA 挑刺。职责分离是防止自我包庇的唯一方法。当 AI 开始成为主力生产单元时我们面临一个问题如何让 AI 遵守同样的职能分工而不是让它自己当架构师、又当开发、还当验收答案就在你手里握着的这三个文件。对比一下两种思路手艺人思维写个 Prompt让 AI 把代码敲出来吹捧一番很聪明啊然后上线。代码坏了微调 Prompt。需求偏了再微调。整个系统的质量完全取决于那一刻 Prompt 的质量没有规律可言。Solution Architect 思维定义三权分立——谁规划谁实现谁验收定义每个角色的职责边界锁死在文件里让 AI和人类开发者无法越权。程序员的价值从此转变不再是敲代码的手感而是定义系统权责边界的能力。让我展开讲。Part 2指挥权——.github/copilot-instructions.md这是第一份文件叫指挥权因为它定义了谁有权指挥谁。Agent 角色与职责| Agent | Role | Responsibility ||-------|------|----------------|| **plan_agent** | 架构师 / 高级数据分析师 | 执行 EDA 理解数据制定数据驱动的任务路线图 || **code_agent** | 资深开发 | 依据 roadmap 实现功能编写单元测试 || **analyzer_agent** | 质检官 (QA) | 运行集成测试验证业务验收标准发布 issue |为什么必须三个角色这不是简单的分工而是Agile 开发的核心诉求开发与验收必须物理隔离。plan_agent架构师不能写代码只能出图纸。它的任务是通过 EDA探索性数据分析去理解真实的数据然后基于数据现实制定任务路线图roadmap。code_agent开发不能定义需求只能按图纸拧螺丝。它的责任是贴着 roadmap 实现功能并确保 100% 的单元测试覆盖。analyzer_agentQA既不规划也不开发只负责挑刺。它要运行集成测试连接真实的数据仓库验证业务验收标准如果有问题就记录在 Issue Tracker 里。核心悟点如果这三个角色混在一起呢AI 会在规划的时候自己想象数据长什么样没见过真数据然后开发出来的代码完美地处理了这个幻想数据最后自己跑一遍单测当然通过了因为 mock 数据就是按照幻想来的然后自信地说一切就绪这就是自我包庇。大多数90%完成的项目死在这里。六阶段工作流让我贴出完整的工作流定义### X0.1 PHASE 0 — Create Agents (Initial Setup)Goal: Create 3 GitHub Copilot agent manifest filesOwner: Manual Setup### X0.2 PHASE 1 — Local Dev SetupGoal: Verify access to all required data sourcesOwner: plan_agent- [ ] Verify data warehouse connection succeeds- [ ] Verify business strategy documentation is readable- [ ] Verify all dependencies installed### X0.3 PHASE 2 — Exploratory Data AnalysisGoal: Understand actual data and strategy BEFORE planningOwner: plan_agentReference: A2 Exploratory Data Analysis- Inspect data warehouse table structure (columns, types, nulls)- Analyze business strategy documents for segmentation rules- Map business rules to actual data columns and aggregations- Document findings in artifacts/eda_report.md### X0.4 PHASE 3 — Data-Driven PlanningGoal: Build PROJECT-SPECIFIC roadmap based on EDA findingsOwner: plan_agentReference: A2.5, A2.6, X1- Review EDA report findings- Align business requirements with data reality- Create artifacts/execution_roadmap.md with tasks, dependencies, and sequence- Assign priority and owner for each task### X0.5 PHASE 4 — Implementation and TestingGoal: Build working software following architecture and test all changesOwner: code_agentReference: B1, B2, B3.4, B4, B51. Read artifacts/execution_roadmap.md (data-driven version)2. Reference EDA report for actual data structure3. For each task (in priority order): - Implement feature following B1 Architecture Principles - Write unit tests using mocks/stubs (B4.1) — target 100% coverage - Run full test suite locally; all tests must pass - Include test results in artifacts/CHANGELOG.md4. Update task status in artifacts/execution_roadmap.md → COMPLETED5. Add feature entry to artifacts/CHANGELOG.md### X0.6 PHASE 5 — Validation and Quality GatesGoal: Verify all work meets quality standards and is ready for productionOwner: analyzer_agentReference: B4, B5, X3, Quality Gates below1. Review code_agent output against quality gates2. If issues found, append entries to artifacts/issues.md3. **Run the Tier 2 integration tests against real data warehouse** (see B4.2): pytest tests/test_integration.py -v -m integration All integration tests must pass. If data warehouse is unreachable, log a BLOCKER.4. **Run the full pipeline against real data warehouse data** and save the output report: python -m src.main --limit 5000 --output artifacts/report.json --log-level INFO - Verify artifacts/report.json is valid JSON and passes schema validation - Record timing, record count, and segment distribution in artifacts/CHANGELOG.md - This is MANDATORY — a CSV-only smoke test does NOT satisfy this gate5. Validate task completion; update artifacts/execution_roadmap.md → VALIDATED6. Add validation entry to artifacts/CHANGELOG.md为什么这个顺序不能乱大多数团队的做法是需求来了 → 直接开发 → 匆匆上线。这套流程强制你必须先跑 EDAPhase 2 3然后才能编码Phase 4。为什么因为没见过真数据的规划就是空想。在一个零售数据分析项目中我们发现产品说“我们需要按采购频次和商品品类分段”EDA 发现采购频次的数据大量缺失品类信息散布在多个不同字段里规划被迫调整改用订单金额和最近采购日期作为分段依据如果没有 EDA代码会死劲儿去处理一个不存在的列。Part 3目标权——business_requirement.md这是第二份文件叫目标权因为它定义了什么才是成功。AI 有个通病**容易在复杂的对话中偏离目标最后产出一堆精美的废话**——代码很漂亮测试覆盖也不错但完全解决的不是业务问题。这份文件是给 AI 设置的终点线。它必须对照验收标准逐条打勾。验收标准Acceptance Criteria这是一个零售数据分析项目的虚构例子脱敏处理## Acceptance Criteria (验收标准)- [ ] 报告必须聚合客户层面的指标交易频次、商品品类偏好。- [ ] 必须从业务策略文档中提取分级规则。- [ ] 最终报告必须为格式合法的 artifacts/report.json。- [ ] **全链路必须在真实的数据仓库环境下跑通并产出数据。**每一条都有具体的检查点“聚合客户层面的指标”← 这意味着什么不是汇总产品不是汇总地区必须是客户粒度每个客户一条记录。“商品品类偏好”← 不能说推断或估算必须是真实存在的字段值。“从业务策略文档中提取”← 不能靠 AI 胡编必须真的从那份文档里找到规则白纸黑字。“真实的数据仓库环境下跑通”← 单测通过不算必须连接生产数据库用真实数据跑一遍。质量门Quality Gates这是验收的严格检查清单。在 code_agent → analyzer_agent 的边界必须全部打勾### Before code_agent → analyzer_agent1. ✅ All code written and committed2. ✅ All unit tests passing locally3. ✅ Type hints on 100% of functions4. ✅ artifacts/CHANGELOG.md entry created5. ✅ Acceptance criteria checklist completed看起来很简单但All unit tests passing locally是个陷阱。Local 通过 ≠ 真实环境通过。所以在 analyzer_agent 这一侧还有更狠的门### Before analyzer_agent → APPROVAL1. ✅ Code review passed2. ✅ Unit tests: 100% coverage, all passing3. ✅ Type checking clean (mypy)4. ✅ Architecture compliance verified5. ✅ Documentation complete6. ✅ **Tier 2 integration tests run against real data warehouse — all passing**7. ✅ **Full pipeline executed against real data warehouse — artifacts/report.json generated and schema-valid**8. ✅ artifacts/CHANGELOG.md validation entry added9. ✅ artifacts/execution_roadmap.md marked VALIDATED第 6 和第 7 项是真刀真枪集成测试必须跑全链路必须在真库上走一遍最后的报告文件必须过 Schema 校验。这就是验收的铁血标准。很多项目在第 6 项就栽了——因为没人真的连过数据仓库。Part 4约束权文章的重头——technical_restrictions.md这是整套系统最硬核的部分。如果说前两份文件是治理框架这一份就是工程底线。它定义了什么样的代码、什么样的流程、什么样的输出才能在这套系统里活下来。4.1 强制 EDA没见过真数据的代码全是幻觉我想强调一个观点EDA探索性数据分析不是数据分析师的工作它是整个系统的基础真实。如果你跳过它后面的所有决策都建立在沙滩上。EDA 的五步工作流Step 1数据探索### A2.1 Step 1 — Data ExplorationAnalyze the data warehouse table and document:- Column names and data types- Data distributions (mean, median, quantiles for numeric columns)- Null/missing values per column- Unique values for categorical fields- Date ranges for temporal>TABLE: retail_analytics.customer_transactions_v1Column Analysis:- customer_id: string, 245,680 distinct values, 0 nulls (✓ 主键可用)- transaction_date: timestamp, range 2023-01-01 ~ 2026-04-12, 1.2% nulls (△ 需要处理)- category_code: string, 18 distinct values, 8.5% nulls (△ 需要策略处理)- transaction_amount: decimal, mean128.50, median89.20, 0.3% nulls, outliers 50k (△ 需要 cap)- product_category: string, 12 distinct values: electronics, home, fashion, food, etc.就这几行代码你发现了customer_id是好的主键transaction_date大部分靠谱但要处理 nullcategory_code有缺失需要降级或补全策略transaction_amount需要做异常值处理product_category相对完整和可靠没有这个发现后面的分段逻辑会有多少坑Step 2策略文档深潜### A2.2 Step 2 — Strategy Material Deep Dive1. Extract all text from business strategy documents2. Identify: segmentation criteria, thresholds, customer categories, usage metrics, business rules3. Map each identified rule to the actual data warehouse columns**Output**: artifacts/eda_strategy_analysis.md- Segment definitions with exact criteria and column mappings- Usage metrics and how to derive them from available>### A2.3 Step 3 — Gap AnalysisCompare business requirements with data reality:- What the strategy requires vs. what the data provides- Missing fields, required workarounds, or blockers- Impact of data quality issues on segment assignments- Constraints (date range, granularity, performance)EDA 发现的差距可能是产品想要年交易品类多样性但数据里category_code有 8.5% null → 决策null 当作 Unknown计数时归为一类产品想要客户忠诚度交易频次但transaction_date有 1.2% null → 决策用 MAX(transaction_date) - MIN(transaction_date) 来计算客户活跃周期忠诚度 交易数 / 活跃周期产品想要季节性分析但历史数据只有 15 个月 → 决策季节性不可靠改用近 3 个月趋势Step 4 5EDA 报告 数据驱动的规划### A2.4 Step 4 — EDA ReportConsolidate into artifacts/eda_report.md with:- Executive summary (data sources, key findings, blockers)- Data overview (from Step 1)- Strategy overview (from Step 2)- Business rules mapped to data columns with explicit thresholds- Data quality constraints (from Step 3)- Specific aggregation logic and cleanup steps required- **Recommended task list and priority order for artifacts/execution_roadmap.md**这就是 plan_agent 最重要的产出。不是图纸而是基于现实的图纸。code_agent 拿到这份报告会知道哪些列能用哪些列是垃圾数据的真实分布不是猜的要处理哪些边界情况分段逻辑的具体实现方式成功标准是什么### A2.6 Success Criteria**ALL of the following must be true before handing off to code_agent**:- ✅ Table fully explored; statistics documented- ✅ All columns analyzed (type, nulls, distributions)- ✅ Strategy documents fully extracted and mapped to data columns- ✅ Segment definitions identified with explicit numeric thresholds- ✅ Business rules mapped to actual data warehouse columns- ✅ Gaps between expectations and data reality documented- ✅ artifacts/eda_report.md completed and project-specific- ✅ artifacts/execution_roadmap.md created from EDA findings **If any gap exists or understanding is incomplete**: STOP — do more EDA before planning.如果你跳过 EDA 直接开发等价于在没有勘探的情况下就开始建楼。倒塌是 100% 确定的事。4.2 分级测试单测只是开始很多工程师的理解是写单测 → 单测通过 → 完工。但在这套系统里单测通过只是入场券不是毕业证。Tier 1单元测试离线逻辑### B4.1 Tier 1 — Unit Tests (离线逻辑)**目标**100% 覆盖业务计算工具如分类逻辑函数。**约束**严禁连接生产数据库必须使用 Mock 数据。单元测试用 Mock 数据完全离线速度极快。100% 覆盖的意思是每一条 if / else 分支都要被测试到。这是 code_agent 必须保证的。Tier 2集成测试在线验证### B4.2 Tier 2 — Integration Tests (在线验证)**目标**验证数据仓库权限、Schema 兼容性和端到端全流程。**约束**这是 Phase 5 验收的唯一准入硬指标。集成测试是什么意思连接真实的数据仓库用真实的数据跑一遍整个流水线。import pytestfrom data_warehouse import DataWarehouseSessionfrom src.main import main as run_pipelinepytest.mark.integrationdef test_full_pipeline_on_warehouse(): PHASE 5 gate: Must run against REAL data warehouse warehouse DataWarehouseSession.builder.profile(PROD).getOrCreate() # Step 1: Can we connect? try: table_df warehouse.read.table( retail_analytics.customer_transactions_v1 ) row_count table_df.count() assert row_count 0, Table is empty! except Exception as e: pytest.skip(fData warehouse connection failed: {e}) # Step 2: Can we load a sample and compute segments? sample_df table_df.limit(1000).toPandas() assert len(sample_df) 1000, Sample load failed assertcustomer_idin sample_df.columns, Missing customer_id column asserttransaction_amountin sample_df.columns, Missing transaction_amount column # Step 3: Run the full pipeline (this is expensive) result_json run_pipeline( limit5000, output_pathartifacts/test_report.json ) # Step 4: Validate output schema assert result_json[status] success assertsegmentsin result_json assert len(result_json[segments]) 0 # Step 5: Check segment distribution makes sense segments_df pd.DataFrame(result_json[segments]) vip_count len(segments_df[segments_df[segment] VIP]) basic_count len(segments_df[segments_df[segment] Basic]) # VIP should be smallest, Basic should be largest (usually) assert vip_count basic_count, Segment distribution looks wrong # Step 6: Verify no data quality issues assert segments_df.isnull().sum().sum() 0, Output has NULLs! assert segments_df[segment].isin([VIP, Regular, Basic]).all(), \ Unexpected segment values这个测试贼难通过。因为它接触真实数据真实的数据仓库连接真实的网络波动。但这正是重点单测通过 ≠ 系统可用。在类似的零售分析项目中我们遇到过这样的情况单测全绿 ✓代码审查通过 ✓本地跑通 ✓集成测试一运行…KeyError: product_category为什么因为预发环境的数据仓库表 schema 和开发环境不一样。字段名叫product_category_v2不是product_category。没有 Tier 2这个 bug 上线就是线上故障。4.3 异步纠偏Bug Tracker 作为 Agent 通讯协议分工的最后一环是怎么反馈问题。在传统团队里QA 找到 bug开发说这不是 bugQA 说就是 bug在会议室吵半天。在这套系统里Agent 之间不在对话框里吵架而是通过结构化的 Issue Tracker 协作。Issue 的标准格式## [VAL-YYYYMMDD-NN] one-line summary| Field | Value ||-------|-------|| **id** | VAL-YYYYMMDD-NN || **severity** | BLOCKER / HIGH / MEDIUM / LOW || **status** | OPEN → IN PROGRESS → RESOLVED → CLOSED || **added_by** | analyzer_agent || **timestamp** | YYYY-MM-DD HH:MM || **files** | src/tools/segment.py lines 45–52 || **evidence** | failing test name / error message / log || **suggested_fix** | short guidance for developer || **resolved_by** | code_agent || **validated_by** | analyzer_agent || **closed_at** | YYYY-MM-DD HH:MM |Status 流转OPEN(analyzer_agent 创建) →IN PROGRESS(code_agent 开始修) →RESOLVED(code_agent 修完重新跑测试) →CLOSED(analyzer_agent 验收)真实案例缺失值处理场景analyzer_agent 在 Phase 5 运行集成测试发现问题。## [VAL-20260410-07] Segment calculation fails when category is NULL| Field | Value ||-------|-------|| **id** | VAL-20260410-07 || **severity** | BLOCKER || **status** | OPEN || **added_by** | analyzer_agent || **timestamp** | 2026-04-10 14:23 || **files** | src/tools/segment.py lines 45–52 || **evidence** | Test failure: test_full_pipeline_on_warehouse AssertionError at line 67: NaNs in output || **suggested_fix** | In segment_customer(), handle null category case. Treat as Unknown category. Update category_diversity check to skip nulls. || **resolved_by** | code_agent || **validated_by** | analyzer_agent || **closed_at** | 2026-04-10 16:45 |code_agent 看到这个 Issue 后的行动打开src/tools/segment.py找到第 45–52 行看当前逻辑plaintextcategories len(customer_data[‘category_code’].unique())发现问题如果category_code里有 NaNunique()会把 NaN 算进去导致长度不对修复plaintextcategories len(customer_data[‘category_code’].dropna().unique())重新跑所有单元测试都通过更新 Issue 的 status: RESOLVED让 analyzer_agent 重新跑集成测试analyzer_agent 的验证重新跑test_full_pipeline_on_warehouse确认✅ 集成测试通过✅ 输出的artifacts/report.json没有 NaN✅ 段分布看起来合理然后关闭 Issuestatus → CLOSED记录 closed_at 时间戳。这个过程的关键点Issue 是结构化的不是聊天记录问题有明确的证据哪个测试失败了修复有具体的指导不是别这样而是试试这样修复完了要重新验收不是 code_agent 自己说我改好了Part 5整体协调——六阶段工作流的完整图景我们已经分别讲了指挥权、目标权、约束权。现在把这些串起来看看完整的工作流是什么样的。工作流图PHASE 0: Create Agents (Manual Setup) ↓PHASE 1: Local Dev Setup (plan_agent验证数据源) ↓PHASE 2: Exploratory Data Analysis (plan_agent跑EDA) ↓PHASE 3: Data-Driven Planning (plan_agent出roadmap) ↓PHASE 4: Implementation Testing (code_agent开发单测) ↓PHASE 5: Validation Quality Gates (analyzer_agent集成测试验收) ↓APPROVED (所有质量门通过可以上线)每个 Phase 的守卫PHASE 2→3 的守卫EDA 必须完整If any gap exists or understanding is incomplete: STOP — do more EDA before planning.你不能跳过 EDA。必须真的理解了数据才能规划。PHASE 3→4 的守卫Roadmap 必须数据驱动### A2.6 Success Criteria (before code_agent can start)- ✅ Table fully explored; statistics documented- ✅ All columns analyzed (type, nulls, distributions)- ✅ Segment definitions identified with explicit numeric thresholds- ✅ Business rules mapped to actual data warehouse columns- ✅ artifacts/execution_roadmap.md created from EDA findingscode_agent 不能说EDA 报告里没提这事而自作聪明。必须严格按 roadmap 来。PHASE 4→5 的守卫Quality Gates### Before code_agent → analyzer_agent1. ✅ All code written and committed2. ✅ All unit tests passing locally3. ✅ Type hints on 100% of functions4. ✅ artifacts/CHANGELOG.md entry created5. ✅ Acceptance criteria checklist completed这是 code_agent 对自己的承诺。如果有一项不满足就不能交给 analyzer_agent。PHASE 5 的守卫Integration 必须真实### Before analyzer_agent → APPROVAL6. ✅ **Tier 2 integration tests run against real data warehouse — all passing**7. ✅ **Full pipeline executed against real data warehouse** — artifacts/report.json generated and schema-valid8. ✅ artifacts/CHANGELOG.md validation entry added9. ✅ artifacts/execution_roadmap.md marked VALIDATED这不是 code_agent 的任务。analyzer_agent 必须亲自跑一遍看到 green 的 test看到生成的 JSON 文件。文件的流转整个流程通过三个关键文件协调文件创建者读者内容artifacts/eda_report.mdplan_agentcode_agent, analyzer_agent数据现状、分段规则、边界情况artifacts/execution_roadmap.mdplan_agentcode_agent, analyzer_agent任务列表、依赖关系、状态追踪artifacts/CHANGELOG.mdcode_agent analyzer_agent所有人实现记录、测试结果、验收记录artifacts/issues.mdanalyzer_agentcode_agent问题记录、修复跟踪artifacts/report.jsoncode_agent (Phase 4)analyzer_agent (Phase 5)最终输出必须是真实数据仓库跑出来的这些文件就像神经网络的突触让三个 Agent 能在没有实时对话的情况下完美协调。Part 6Solution Architect 的溢价到这里我要问一个问题为什么要费这么大功夫直接让 AI 一个人搞不行吗答案是短期可以长期不行。程序员的三个进化阶段L0手艺人— 只会敲代码出题“写个客户分层系统”做法“行我给你敲”质量取决于那一刻的 Prompt 质量波动极大可维护性依赖个人可复用性几乎为零L1工程师— 知道怎么写好代码出题“写个客户分层系统”做法“我用 TDD、设计模式、100% 单测覆盖”质量稳定代码漂亮可维护性代码可维护但需求理解可能有偏差可复用性还是依赖这个人的代码库L2Solution Architect— 能定义系统的权责边界就是你现在学的出题“用这三个文件 六阶段流程解决这个问题”做法“我不管你是人还是 AI只要你遵守这套框架”质量框架本身就保证质量因为有三权分立、质量门、真实数据测试可维护性极强因为所有决策都记录在文件里可复用性这套框架可以克隆到任何项目三个文件的威力让我再强调一遍这三个文件加在一起是什么.github/copilot-instructions.md← 权责分工谁规划plan_agent谁开发code_agent谁验收analyzer_agent每个人的输入输出明确到文件级别business_requirement.md← 目标锚定什么是成功逐条列出验收标准怎么证明成功质量门 checklist没有达到就是没完成technical_restrictions.md← 工程底线必须跑 EDA禁止盲目编码必须分级测试单测 集成测试必须真实数据验证数据仓库集成测试必须记录所有问题结构化 Issue Tracker把这三个文件丢给任何一个老旧的代码库它立刻就能长出一套为其量身定制的、具备大厂规范的开发流水线。程序员的新溢价在 AI 时代你的价值不再体现在敲代码的手感上而是能否定义清晰的权责边界← 这是架构师的核心技能能否设计有效的质量门← 这是工程管理的核心技能能否写出具体可执行的规范文件← 这是沟通的核心技能你手里握着这三个文件就握着一台自进化、可克隆的生产力机器。同一套框架可以套用到推荐系统不同的 AI 模型尝试风控模型不同的特征工程方案数据平台不同的表结构和 ETL 流程搜索引擎不同的排序算法框架不变具体实现的细节会变。但那套先 EDA、再规划、再开发、再验收的逻辑永远有效。总结没代码不 BB这就是 Harness Engineering 的全貌。如果你要我用一句话总结我会说这套系统的核心不是某个技术决策而是一种治理哲学——通过明确的分工、明确的目标、明确的约束把 AI和人类开发者变成工业级的生产单元而不是聊天机器人。没有魔法只有三个 Markdown 文件六个清晰的阶段若干个质量门结构化的 Issue Tracker一个必须用真实数据验证的铁血要求做到这些你就不再是代码手艺人而是解决方案架构师。你的价值从此开始溢价。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
相关文章
Snippy快速指南：10分钟掌握单倍体变异检测与核心基因组比对
Snippy快速指南：10分钟掌握单倍体变异检测与核心基因组比对 【免费下载链接】snippy :scissors: :zap: Rapid haploid variant calling and core genome alignment 项目地址: https://gitcode.com/gh_mirrors/sn/snippy Snippy是一款专注于快速单倍体变异检测…
数仓面试提问：项目里最难的是什么，如何回答？
这是一道常见的“分水岭”问题。几乎所有的求职者都有几率碰到该问题，也是求职者最头疼、最恶心的一道题目，今天我们就聊一聊，当求职者遇到该问题时应如何应对，本文总结了四类场景供求职者参考。 首先，我们来看一下当面试官抛出这个问题时的真实意图是什么？ 项目的真实性…
VisualCppRedist AIO终极指南：3个技巧解决Windows运行库安装难题
VisualCppRedist AIO终极指南：3个技巧解决Windows运行库安装难题 【免费下载链接】vcredist AIO Repack for latest Microsoft Visual C Redistributable Runtimes 项目地址: https://gitcode.com/gh_mirrors/vc/vcredist 你是否曾经在安装某些软件时遇到&qu…
YI-1.5-9B训练数据与预训练技术：500B tokens的优化策略
YI-1.5-9B训练数据与预训练技术：500B tokens的优化策略 【免费下载链接】YI-1.5-9B 项目地址: https://ai.gitcode.com/hf_mirrors/Rose/YI-1.5-9B YI-1.5-9B是一款基于Llama架构的高性能语言模型，通过500B tokens的大规模预训练数据和先进的优化…
3步解锁原神帧率限制：安全高效的游戏体验优化指南
3步解锁原神帧率限制：安全高效的游戏体验优化指南 【免费下载链接】genshin-fps-unlock unlocks the 60 fps cap 项目地址: https://gitcode.com/gh_mirrors/ge/genshin-fps-unlock 还在为《原神》60帧的限制感到困扰吗？genshin-fps-unlock是一款…
Qbot量化交易框架完整指南：从本地部署到AI策略实战深度剖析
Qbot量化交易框架完整指南：从本地部署到AI策略实战深度剖析 【免费下载链接】Qbot [🔥updating ...] AI 自动量化交易机器人(完全本地部署) AI-powered Quantitative Investment Research Platform. 📃 online docs: https://ufund-me.github…
IBM与Red Hat携手打造企业开源安全“清算中心“
开源代码在企业领域无处不在，据估计，超过90%的财富500强企业的软件供应链中都包含开源代码。然而，开源代码安全漏洞问题由来已久，识别和修复这些漏洞对安全团队而言几乎是一场没有尽头的持久战。IBM与Red Hat正押注于一项名为&quo…
终极指南：如何快速部署AceGPT-v2-32B模型进行阿拉伯语文本生成
终极指南：如何快速部署AceGPT-v2-32B模型进行阿拉伯语文本生成 【免费下载链接】AceGPT-v2-32B 项目地址: https://ai.gitcode.com/hf_mirrors/huangjingwang/AceGPT-v2-32B AceGPT-v2-32B是一款基于Qwen1.5-32B开发的大语言模型，特别专注于阿拉…
Gemma 4本地部署实战：Mac/Windows/树莓派全平台低显存运行指南
1. 项目概述：为什么现在必须认真对待 Gemma 4 的本地部署 Gemma 4 不是又一个被营销话术堆砌出来的“新模型”，它是 Google 在轻量级开源大模型赛道上一次真正意义上的代际跃迁。我从去年初开始系统性测试各类 4B–7B 级别模型在消费级硬件上的推理表现…
告别激活烦恼：IAR Embedded Workbench 许可证管理的最佳实践与合法替代方案探讨
IAR Embedded Workbench 许可证管理全指南与合规开发方案在嵌入式开发领域，IAR Embedded Workbench 以其高效的编译器和强大的调试功能著称，成为众多工程师的首选工具。然而，随着团队规模扩大和项目复杂度提升，许可证管理问题逐渐…
赤铁矿磨矿过程运行优化控制软件系统【附程序】
✨ 长期致力于赤铁矿磨矿过程、磨矿粒度、数据驱动、运行优化控制、神经网络、案例推理、规则推理、软件系统研究工作，擅长数据搜集与处理、建模仿真、程序编写、仿真设计。 ✅ 专业定制毕设、代码 ✅ 如需沟通交流，点击《获取方式》 （1&…
终极指南：如何使用Attu轻松管理你的Milvus向量数据库
终极指南：如何使用Attu轻松管理你的Milvus向量数据库 【免费下载链接】attu The Best GUI for Milvus 项目地址: https://gitcode.com/gh_mirrors/at/attu Attu是一款专为Milvus向量数据库设计的现代化AI工作台管理工具，提供全面的可视化界面&…
Win10/Win11下Realtek 8188GU网卡驱动感叹号？别急着扔，试试这个手动安装的野路子
Realtek 8188GU网卡驱动故障深度修复指南：从原理到实战当设备管理器里那个顽固的黄色感叹号挥之不去，而你已经尝试了所有"标准操作"——Windows自动更新、第三方驱动工具、甚至重启大法——却依然无济于事时，是时候换个思路了。这篇…
AnolisOS 8.8安装源配置踩坑实录：从‘设置基础软件仓库时出错’到成功联网的保姆级指南
AnolisOS 8.8安装源配置实战指南：从诊断到解决方案的全流程解析当你在安装AnolisOS 8.8时遇到"设置基础软件仓库时出错"的提示，这通常意味着系统无法访问或识别安装源。这个问题看似简单，但背后可能涉及网络配置、镜像选择、启动参…
基于树莓派Pico的反应速度测试游戏：从GPIO编程到状态机实战
1. 项目概述与核心思路最近在整理工作室的电子元件，翻出来几个闲置的街机按钮和一块树莓派Pico，灵机一动，决定做个简单又有趣的反应速度测试游戏。这个项目非常适合想入门嵌入式开发的朋友，它不涉及复杂的传感器和通信协议&#x…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…